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[57] ABSTRACT 

A method for enabling users over a network or over the 
WWW to interact with an interactive sales representative 
system for providing sales guidance. The system offers the 
user products, services, or ideas (the "products") according 
to parameters collected from the user. The system guides the 
customer to retrieve the desired products. If the system does 
not have a product matched to the customer requirements, 
preferably it will operate a mechanism for suggesting alter- 
natives which are the closest to the customer requirements. 
The system will execute various sales tools and techniques 
to help and assist the customer and to convince the customer 
to purchase a product. By guiding the customer to the target 
product, the system will shorten the search cycle for the 
customer as well as find better matched products. The 
system will provide market advisory, suggest, recommend, 
discuss (in written form and optionally voice form), 
comment, advise the customer regarding the products. The 
system might advise the customer in any other aspects as 
well (such as providing personal feedback). The system adds 
graphics, animation, 3D, movie clips, voice and other effects 
to make the session enjoyable for the customer. The system 
is capable of executing various tools and techniques to 
improve its sales capabilities and bring better sales results. 

6 Claims, 22 Drawing Sheets 
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VIRTUAL SALES PERSONNEL It is another object of the present invention to provide 

intelligent interactions with a computer user for the purpose 

FIELD AND BACKGROUND OF THE 0 f securing a sale. 

INVENTION j t k y et ajjQjhej object of the present invention to provide 

The present invention relates to virtual sales personnel, 5 such intelligent interactions through a GUI. 

and more particularly, to software which is capable of It is still another object of the present invention to provide 

assisting a computer user to complete an on-line sales SU ch a GUI through a Web browser, such that the virtual 

transaction in a substantially similar manner as a human sales representative is accessed through the Internet, 

sales representative. Alternatively, the GUI is provided through an applet or other 

As the Internet grows, many Web sites are becoming 10 stand-alone software program, such that the virtual sales 

connected and more corporations are trying to do business representative is accessed through a locally operated soft- 

on the "Web". Although most information is still given ware module. 

freely on the Internet, an increasing number of organizations These and other objects of the present invention will be 

are attempting to actually sell their products electronically explained in further detail with regard to the description, 

by charging a credit card. As credit card security problems figures and claims given below. 

are being resolved, the area of electronic sales, or Electron Hereinafter, the term "Web browser" refers to any soft- 

Commerce (e-commerce) has been developing rapidly. The wafe m which can d[s { ^ graphics, or both, 

new and exciting point about e-commerce is the ability of from Web Qn Wf)rld wkJe Web ^ Hereinafter, the 

every one, almost anywhere on the globe to which a Web tcrm <<Wcb „ refcrs tQ documcnt writleD in a 

connection is available, to access any commercial business mafk h includi ng, but not limited to, HTML 

offerings catalog implemented as a Web site. Moreover, the (h t ext mak language) or VRML (virtual reality 

user, can access this service anytime, 24 hours a day, seven modeling language), dynamic HTML, XML (extended 

f V l I W f u H ° WC T' I™ ai ? a m WbCh V1ItUaI u 10 ^ la ! mark-up language) or related computer languages thereof, as 

far behind their actual, physical counterparts ism the area of ^ weU as tQ any collection of such documents rea chable 

sales representatives. through one specific Internet address or at one specific 

A common practice worldwide in actual physical stores is Wor i d Wide Web sitej or any document obtainable through 

to have sales representatives or sales persons. These sales a particular URL (Universal Resource Locator). Hereinafter, 

representatives help the customer to understand the product lhe « Web site » refers t0 at least one Web page> and 

and its benefit to the customer, as well as enabling customers 3Q preferably a plurality of Web pages, virtually connected to 

to find the needed product quickly. In addition, the sales f orm a coherent group 

representative can advise the customer on product related Hereinafter, the term "applet" refers to a self-contained 

issues, including the vmues of competing brands. In this software mo(Jule fa an guch as Java 

sense, the sales representative is the technical expert who of mostmaed M an ActiveX TM ^ ntrol . 

generally advises the buyer. However, since the sales rep- _ c . n f 

resentative is also an employee of the store, the sales 35 Hereinafter, the term "network" refers to a connection 

representative should also promote certain products accord- between any two computers which permits the transmission 

ing to the interest of the business and also sell as many ofdata Hereinafter the term compute^ includes, but is not 

products as possible. hmited to > P ersonal computers (PC) having an operating 

, t *c . , system such as DOS, Windows™, OS/2™ or Linux; Mack- 

As a basic example, if customers go to a computer , TM . , • i A vatm ^ ,u 

, , c . r A ' . . u i 0 intosh™ computers; computers having JAVA™ -OS as the 

hardware or software store, a sales representative helps them . . . • , , . 4 . . 

, JtL . t « . ^ * . . operating system; and graphical workstations such as the 

find the appropriate product. Even when ordering a product r w * TM jot ^ ,. ™ 

,« l. , 4 i * *l. computers of Sun Microsystems™ and Silicon Graphics™, 

over the phone, a sales representative can speak to the , r t , , . e t . r 

' , . r , . * . . . 4 T , and other computers having some version of the UNIX 

customer directly and give adv.ee Unfortunately, when the £ such ^ XTM of gQLARIS™ of Sun 

customer wishes to buy a product through the Internet only 45 ^ *ems™; or any other known and available operat- 

a menu and pictures are shown. No advice, no knowledge, ; „ . ' „„ 7 . , TMM . . / , . 

r ing system. Hereinafter, the term "Windows™ includes but 

no expertise, no confidence in the purchase is provided. . ** , . „ T . . ne .~. . - TM . . . . u „ 

rrn -c iU t j . A * a t t is not hmited to Windows95 , Windows 3.x in which x 

Thus, if the customer does not understand computers, for , .„„ w . . vm-M w j no tm 

, . u ii * u *u u L 1 is an integer such as "1 , Wmdows NT™, Windows98™, 

example, he or she will not purchase one through a virtual ,, 7 . , , , , . ' r 

,« j , . . j • • • i j Windows CE™ and any upgraded versions of these oper- 

store on the Internet since no advice ^ provided 50 ^ g sys(ems by ^^Jf^ (Seattfc> Wash-> USA) F 

Uearly, one solution would be to add the Sales Repre- _ T . _ . , , . „ • i n 

sentative function to the Internet virtual store. Currently, the Hereinafter, the phrase disphy a Web page mcludes all 

merchant would need to hire 3 shifts of human representa- act ; ons '° render ^ a ,P ortlon °f ^ 1Df ° r - 

tives for a 7 day work week, including holidays. Then, the ™*>non the Web page avartable to the computer user As 

merchant would need a chat system in a cell center of some S5 SUCb ',* 6 P hrase f ln , c udes ' b ^ ■ no ' llml ed ,0 ' ,he 

sort for enabling communication from these "human" Sales ^ °i smi ? g«P hlcal L information, the audible 

Representatives to the users over the Web. Thus, this solu- P"> duct ™ of audio mformation, the animated visual display 

tion is difficult and expensive to implement. of 21,111141,011 and the v * ual d,s P la y of v,deo stream data - 

There is thus a need for, and it would be useful to have, "T™^' the \f m JSffT.* Wh ° T'^ "f 

a virtual sales representative accessible through the Internet 60 ™ b other GU | and navl S ates tbrou S h 

or via some other electronic connection, with which a ,he s y stera of lhe P resent mention, 

potential customer can communicate through interactions Hereinafter the word "product" includes both physical 

with a GUI (graphical user interface) such as a Web browser. products and services (tangible and intangible products), as 

well as ideas and concepts. 

SUMMARY OF THE INVENTION 65 Abbreviations in the text are as follows: 

It is one object of the present invention to provide a virtual VSD — Virtual shop designer (Sales Representative 

sales representative. Designer) 
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VS — virtual shop (Sales Representative) The system has at least one application file per business 

SEU— The core of the Sales Engine Unit (SEU) application. The application file is built by the builder 

system by interviewing a sales representative or other expert 

BRIEF DESCRIPTION OF THE INVENTION individuals regarding the products and strategy of the 

5 desired sales. The interviewing is done in a process of an 

The present invention is of a virtual sales representative intc Ui g ent "chat-like" session, where the sales person or 

for interacting with a customer browsing a virtual store Web other qualifying personn el answers questions asked by the 

site, for example. The virtual sales representative can ask systcm according to instructions, explanations and guidance 

questions and receive answers from the customer. The tne intelligent system, 

reverse is also possible, in which the customer poses the 10 fe 

question. In addition, the virtual sales representative can be BRIEF DESCRIPTION OF THE DRAWINGS 
programmed to guide the sales transaction in order to 

promote certain products, for example, or in order to more ^ forgoing and other objects, aspects and advantages 

easily provide the customer with the desired product. Such Wl11 be better understood from the following detailed 

guidance is provided through software modules capable of 15 description of a preferred embodiment of the invention with 

"intelligent" interaction with the customer, as described in reference to the drawings, wherein: 

more detail below. The operation of the virtual sales repre- FIG. 1 is a schematic block diagram of an illustrative sales 

sentative is as follows. representative system of the present invention; 

First, the user navigates via the Web browser to a site FIG. 2 is a schematic block diagram of an illustrative sales 

where the system operates. The Internet sales representative 20 en gine unit of me present invention; 

system of the present invention then interacts with the user, FIG. 3 is a schematic block diagram of illustrative GUI 

advises, guides, consults, suggests, comments and negoti- components of the present invention; 

ates with the user regarding items available for sale or any mG 4 fc a schematic block diagram of an illustrative 

other topic to be conveyed. The system offers alternatives in cnginc corc interface according to the present invention; 

case the requested item is not available. The system works 25 cip * ■ u *■ i_i 1 r n * 

. 4 , . « j 1, FIG. 5 is a schematic block diagram of an illustrative 

to convince the user to buy certain products and generally commenls processing module according t0 the , 

promotes the products. invention; 

The system is installed over a Web server and preferably CT/ ^ ^ . , t . U1 . c .„ . 

' l4 1 r™ u r • FIG. 6 is a schematic block diagram 01 an illustrative 

serves many users simultaneously. The number of users is f , , j- 4 4 i_ 

.. , . r „ t . 3 ... . c „ preferences module according to the present invention; 

limited substantially only by the capacity of the server itself. 30 r t 

_ . . , .. .... FIG. 7 is a schematic block diagram of an illustrative 

me system accompanies me customer trom the initial arithmelic module accordin2 

to the cresent invention: 

stage or requesting an Internet sales representative, through 

the stage of determining the needs of the customer, guiding Fia 8 * a schematic block diagram of an illustrative 
the customer to the desired products while maintaining a s y stem of departments according to the present invention; 
product and market advisory, and generally suggesting or 35 FIG. 9 shows a first embodiment of the system of dep art- 
recommending, and discussing or commenting with regard ments according to the present invention; 
to the product through the purchasing process. The system FIG. 10 shows a second embodiment of the system of 
follows a line of reasoning in order to sell to the end user. departments according to the present invention; 
The system optionally continues through the credit card FIG. 11 shows a third embodiment of the system of 
charge process with a secure mechanism for charging the 40 departments according to the present invention; 
car ^* FIG. 12 shows a fourth embodiment of the system of 

The system feature a "Detection engine" mechanism to departments according to the present invention; 
recognize characteristics of the user and to modify the nG 13 is a schematic block diagram of an illustrative 
session from user to user according to the individual. Hie 45 system of offering altema tives according to the present 
"Detection engine" is capable of sensing certain behavior invention- 
patterns by the user, such as: curious about more CTO . . 1 r ... . 
f P 7 \ , , , FIG. 14 is a schematic block diagram of an illustrative 
information, serious customer, not a serious customer, and c . . . * tl _ 
^ e ^ e ' 7 7 financial purchase manager according to the present inven- 
tion; 

The system, following a signal from the "Detection 50 FI(J ls is a wdmaa&l block diagrara of an Ulustra tive 

engtne or following a request from the user, preferably can credjt cha man accoK)in (0 ^ t 

change the session from the logic based system to a chat „.„ ... . . , " . ... 

mode with a "live" human sales representative whenever J 16 15 a "taan*^ block d.agram of an illustrauve 

and if one is avaUable. The "live" sales representative is dement messaging system according to the present 

preferably briefed regarding the customer's interests (if any 55 mventl0n > 

were demonstrated), such that the session will preferably p IG. 17 is a schematic block diagram of an illustrative 

continue smoothly from the logic based system to the chat e-sho P builde r according to the present invention; 

mode. FIG. 18 is a schematic block diagram of a first illustrative 

The system, following a signal from the "Detection portable code implementation of the system of the present 

engine" optionally and preferably writes the email addresses go mventl0n i 

of all the users which the "Detection engine" found to be FIG. 19 is a schematic block diagram of a second illus- 

interesting or important to a dedicated log file. trative portable code implementation of the system of the 

The system performs the functions described above also present invention; 

on a stand alone system without the Internet as well as over FIG. 20 is a schematic block diagram of an illustrative 

a network system, using either Internet technologies such as 65 cnat transfer system according to the present invention; 

browsers and servers or a dedicated Graphical User Interface FIG. 21 is a schematic block diagram of an illustrative 

(GUI) without Internet or web tools. chat session according to the present invention; and 
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FIG. 22 shows an illustrative parser according to the determining if the fragment satisfies a rule of the rule base. 

present invention. The rules are decomposed into at least one sub-condition or 

ncTAii pn np^ruiPTinw he thp mle portion by the EngineCore routine. The actual logic 

DETAILED DE^R^TTON OF THE of ^ mles J handles by ^ module 

S "Equate" (block 44). This function will return the value 

The present invention is of a virtual sales representative TRUE preferably if and only if all the processing of the 

for interacting with a customer browsing a virtual store Web sub-conditions returns TRUE. At the very least, the function 

site, for example. The virtual sales representative can ask should return the value TRUE substantially only if the at 

questions and receive answers from the customer. The least one fragment satisfies at least one rule of the rule base, 

reverse is also possible, in which the customer asks the if logic testing returns the value TRUE, the action or 

questions and the virtual sales representative gives the actions required in response are performed with the module 

answer. In addition, the virtual sales representative can be labelled "Perform" (block 40), which is responsible for 

programmed to guide the sales transaction in order to recommending the product for the user. The purchase is then 

promote certain products, for example, or in order to more made by the user by clicking the "purchase" button of GUI 

easily provide the customer with the desired product. Such (block 22, see FIG. 1), thereby launching the "Purchase 

guidance is provided through software modules capable of Mechanism" module (Block 50). 

"intelligent" interaction with the customer, as described in "FireRule" (block 32) algorithm uses the working 

more detail below. memory directly to determine the rule being examined, by 

The principles and operation of a method for providing a savin S the P osition of the mle ™ the ^ which » the trace 

virtual sales representative to a computer user according to marker. 

the present invention may be better understood with refer- "FireRule" (block 32) uses "Equate" (block 44) to deter- 

ence to the drawings and the accompanying description, it mine that toe rule conditions are satisfied. "Equate" (block 

being understood that these drawings are given for illustra- 44 ) asks user questions regarding those conditions, using 

five purposes only and are not meant to be limiting. toe module "AskUser" (block 36). "AskUser" (block 36) 

Referring now to the drawings, FIG. 1 is an exemplary „ uses a flag to stop the output of the questions to the user after 

block diagram of a virtual sales representative system the first question. Then, "FireRule" (block 32) launches the 

according to the present invention. Block 10 of the system "lookAhead" software module (block 30), which processes 

shows the Sales Engine Unit core routines: rules linkage, th e entire list of rules and tries to satisfy a rule, based on the 

"lookAhead", reading information from the e-shop and basic information already obtained. This is done in order to break 

rules processes as described in more detail below. Block 12 30 lhe dependency between the order of the product 

is the Business Logic module for controlling the depart- recommendation, the order of the rules and the "length", or 

ments and business strategies. Block 14 shows the Financial number of conditions, in the rule. The main function 

Purchase Management system, including the credit card employed is "FireNextRule" (block 34). 

charge security of the present invention. Block 16 includes When a rule is processed and fails from lack of 

various arithmetical functions such as the arithmetic parser. 35 information, the condition is indicated with the appropriate 

Block 18 shows the Application Support module, including flag. In this case, the module "lookAhead" (block 30) starts 

the generation of sales comments, department messages and at the following rule, returning to the current rule when 

multimedia output. Block 20 is the module providing the "FireNextRule" (block 34) is finished. If the rule fails from 

Web server technologies and block 22 is the GUI (graphical contradictory information— "lookAhead" (block 30) goes to 

user interface) platform for interactions with the user. Block 40 lhe following rule, returning to the following rule when 

24 is the E-Shop and includes links to the various modules "FireNextRule" is finished. 

required for the interaction of the virtual sales representative "FireRule" (block 32) is not finished until every rule in the 

and the user. Block 26 is a software module providing the rules list has been fully processed and either proven or 

option to transfer the interaction to "chat mode" with user. failed. 

Block 28 is the Detection Engine. All of these software 45 "FireRule" (block 30) is the shell to the "FireNextRule" 

modules and components of the present invention are (block 34) routine. The tasks performed are used to preserve 

described in more detail below. the system status before launching "FireNextRule" (block 

Turning now to the sales engine unit (SEU), FIG. 2 shows 34). 

a more detailed description of SEU 10, SEU 10 interacts Before "FireNextRule" (block 34) is launched, "lookA- 

with the user using a CGI or other web server interface, as 50 head" (block 30) saves the current position in the list of rules 

shown by the block labelled "Interface to the SEU" (block in order to be able to return after "FireNextRule" (block 34) 

52), which calls the main SEU procedure labelled "Engi- is finished. The current position is passed to "lookAhead" 

neCore" (block 42). "Interface to the SEU" (block 52) (block 30) as an argument. "lookAhead" (block 30) then 

handles the I/O (input and output) which consists of ques- restores the previous position after remrning from "FireN- 

tions and answers from the user. 55 extRule" (block 34). Optionally, if "Equate" (block 44) 

Inside SEU 10 there are global functions for processing turned a flag regarding missing information in the process 

the rule base, such that the answer of the user is analyzed rule processing, "lookAhead" (block 30) turns it off. 

according to the rule base of the E-shop (see below), and to The software module named "FireNextRule" (block 34) is 

determine if another question is to be asked or if a type of the "twin" of "FireRule" (block 32), in the sense that it 

a product can be recommended to the user. "ProcessRule- 6Q makes the same use of memory and calls the same routines 

sList" (block 38) is initiated and starts the process by calling as "FireRule" (block 32), with the exception of "lookAhead" 

the software module "FireRule" (block 32). "FireRule" (block 30). "FireNextRule" (block 34) works until all the 

(block 32) then walks through the list of rules with a trace rules are processed, discarding and performing any rule that 

marker to determine if any rule can be satisfied yet, in order can be proven with the current stack of information (without 

to guarantee the alertness and efficiency of the system. 65 external input). 

The SEU includes which is a logic unit for decomposing Technologies such as CGI operate within the framework 

the answer of the user into at least one fragment and for of sequentially entering and exiting a system. When output 
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takes place the system is shut down until the user submits the 
form and then the program entered again. In order to 
accomodate this structure, if rule performance involving 
output occurs and the system exits from "FireNextRule" 
(block 34), the previously saved position of the rule which 
"FireRule" (block 32) was last processing is not saved. 
Instead, when the program is re-entered, the previously 
saved position acts as a flag, such that the system continues 
from "FireNextRule" (block 34) using that flag. "FireNex- 
tRule" (block 34) is used in other mechanisms of the systems 
besides "lookAhead" (block 30). 

The "Equate" (block 44) software module provides the 
support for the entire session. The rules to be evaluated 
consist of fragments of conditions, which in combination 
enables the virtual sales representative to recommend a 
particular product to the user. 

"Equate" (block 44) allows use of any of the logical 
operators {and, or, =} and the arithmetical operators of 
comparison {=, =, <, >, <=, >=}. "Equate" (block 44) is a 
recursive routine formally defined as follows: Equate (Parti) 
and Part2): Equate(Partl) Equate(Part2) 

The rule is considered proven if the invocation of 
"Equate" (block 44) both on Parti and Part2 returns TRUE. 

Equate (Parti or Part2): Equate (Parti) Equate (Part2) 

Now the rule is considered proven if either the invocation 
of "Equate" (block 44) on Parti returns TRUE or the 
invocation of "Equate" (block 44) on Part2 returns TRUE. 

For any other operator — Equate(X) (see "Equate" block 
44) compares the pattern of the condition to the already 
known information. It returns TRUE if the right side of the 
condition is present in the stack of known information. 
Otherwise, it fails. 

In the case of missing information "Equate" (block 44) 
calls "AskUser" (block 36) to get more information from the 
user by asking questions. In case the output is blocked, by 
"lookAhead" (block 30), for example, "Equate" (block 44) 
also returns FALSE. To distinguish between the different 
cases, a "missing_value" flag is set. 

The "Perform" (block 40) software module is imple- 
mented as a unique routine used to perform numerous tasks, 
as described with reference to the remaining Figures below. 
"Perform" (block 40) is initiated once a rule has been 
proven, such that all the conditions were fulfilled and a 
product can be recommended. In order to recommend the 
product, the "Try Re commend" (Block 46) routine is started, 
which will find the product in the virtual shop and it's 
text/url/html reference, and send the information back to the 
user with the CGI or other Web server technology transac- 
tion. 

"Perform" (block 40) writes to the memory all the prod- 
ucts that were recommended, information which shall be 
used later for other mechanisms such as "CC Charge". 
"Perform" (block 40) can also recommend several products 
by the same condition, using the logic operator "and". This 
saves constructing the same rule multiple times. 

The above 4 tasks of the "Perform" (block 40) software 
module can be used in various combinations through the 
same rule, linked by the operator "and". The "AskUser" 
(block 36) routine is used to generate the query output. After 
the first question is sent, "AskUser" (block 36) turns the 
"question_on" flag, blocking further output until that flag is 
removed by another routine. 

"AskUser" (block 36) uses mechanisms defined in the 
"Interface to the SEU" (Block 52) to generate a query with 
all the related multimedia attributes (sound, video, pictures, 
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text/html). The only argument is the query's name as defined 
in the virtual shop. As noted above, "TryRecommend" 
(Block 46) is used to generate another type of output: the 
product recommendation text. This software module can 

S also be used to generate "normal" text answers without 
recommending any product. 

The difference between a product and a text answer is 
being processed by the "Interface to the SEU" (Block 52) 
which is called here to complete the final output. "TryRec- 

10 ommend" (Block 46) works differently based upon the 
"sales strategy" choses. For "human" sales representatives, 
the module generates an immediate output without any 
reference to the memory. In the "quick" or "cruiser" mode, 
the module gathers the products and text references to a list 
output as the session is finished ("FireRule" (block 32) 

15 finished rule processing). 

In addition to the "TryRecommend" (Block 46) software 
module, an option is given to use "TryGetConstText". 
"TryGetConstText" is a unique routine which enables a 

2Q "canned" text to be combined with information generated on 
the fly. For example: "The time now is 15:00" or "You have 
to pay us $23000". 

If the VSD wants to use sentences of the form above in the 
system of the present invention, the 'Variable" must be 

25 declared, with the text part of this type of answer. The 
information should be glued to the end of the text and is 
received by the rules in the e-shop. This part of "TryGet- 
ConstText" has widespread usage especially in the Arith- 
metic module. 

30 ''TryGetConstText" is able to receive a line of text with 
"to-be-replaced" entries and a list of replacements 
(variables), as well as to change the whole "to-be-replaced" 
entries with the corresponding entries in the list. That means 
that a different line of text will always be provided, based on 

35 the variables' value at the moment of replacement. 

FIG. 3 is a schematic block diagram of the E-Shop of the 
present invention. The e-shop of the present invention is a 
software package which consists of one or several files 
(depending on the VSD) with the following components: 

40 configuration (internal or external to the rule base); a rule 
base; topic definitions and questions (prompts) to the user, 
which can then be interpreted according to the rule base. For 
example, the query might state "What kind of diamond are 
you looking for?" to the user. Possible answers to the 

45 question (in the case of multi-optional input such as menu) 
are found in the set {One carat, Below on carat, Over one 
carat}. A number of different input format styles are 
possible, such as free input (Block 64) or "menu like" input. 
The output styles include radio (Block 58), check-box 

50 (Block 60), list box (Block 62), button-checkbox (Block 56), 
and optionally button-radio (Block 54). Furthermore, mul- 
timedia references, including pictures, animation, sound, 
etc., can be optionally provided. 
A "negotiation text" to be used in "offering alternatives" 

55 is optionally provided. For instance "Would you agree to 
compromise on the size of the stone and settle for "(One 
carat, 2 carat or any other attribute the current rule requires) 
". See "offering alternatives" section below for more details. 
In addition, a recommendation text — for example "This 

60 "fancy" diamond with the size of 67 carats and the price of 
100000000 U.S. Dollars is the best diamond we can offer 
you". Or — "I recommend 'imaginary car manufacturer 
product 1*. It's a safe, fast car which is ideal for family rides, 
business . . . plus, if you'll buy it before 4.6.1998 (date) I 

65 guarantee you a 78% discount!". 

In addition, a multimedia reference can be presented to 
the user. The reference is a picture in an HTML accepted 
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format to be used in the "Shopping Smart" function icon sorts of information identically, such that the storage of 

(optional — See "Shopping Smart" section below). information in the memory is done by the same patterns and 

Both of the products and topics may be constructed in a {hus » storcd m memory zone, 

database. If the VSD chose to put these topics, products or Variables denned as a pseudo-topics do not contain a 

both of them into a database, the rule looks different. * description. Thus, the SEU does put them to the virtual 

j « . . « <• .« ,«. C vvr j^t- j memory, along with their internally received values, but no 

In this case, instead oi the usual if X=Y and OF and . * * / *• \ ■ ■ t i j ■ *l 

iii m« va*, iiwivaw i vuv " V, ' output (questions) is mvolved dunng the process. 

. . then P where all the topics X, C, . . . and the product P ; * * *i_ octt ■ *u -* c 

. j . . , . 4 , r OT , ' iL *j. A . / The Interface to the SEU is the unit for communication 

reside m a file written in the SL language, the condition (or between me uscr and the main proccdurc of Saks Enginc 

the result if a product) of the rule will contain the following: Unft ( SE U)-"EngineCore" (FIG. 2, block 42) through 

a reference to an external file which is the name of the file; some Communication Environment (CE). Examples of CE 

and the index of the entry corresponding to the topic/ implementations are CGI, ISAPI, Console, GUI of Windows 

product. aud other communication technologies and interfaces which 

The format is "db(<File Name>, <Entry , s index>)". can provide the connection of the user to the SEU. 

This allows better maintenance and flexibility of the 15 The Interface unit reacts with the SEU unit on one hand 

system: for example, the VSD may construct a few different and ttie server on the other hand using 3 routines: 

databases and merely change the references to them to "WebMain"— calls the "EngineCore" (FIG. 2, block 42) 

facilitate different sessions for difference types of users. See ™Uinc which launches the main routine of the engine, 

the section about the "Detection Engine" below for more "Webl^ad -loads the e-shop file "Weblnit -reads the 

configuration file which contains definitions for the com- 
20 munication environment and initializes the server. 

Instead of their contents as described above, the topics ^ S£TJ> 0Q ^ Qthcr hand> ^ scycral frQm 

and the products may contain nothing but an HTML refer- ^ Interface ^ fof ^ aQd output ((hig ^ how ^ S£U 

ence or a link to a specified URL. interacts with the user) as shown in FIG. 4. The "AskUser" 

Another issue that is included in the e-shop is the Business procedure (which resides in the SEU unit) sends questions to 

strategies supported by the SEU, which is contained in a 25 lhe user Jt fa conGgaiMc t0 send ail questions one by one 

business strategy unit (not shown) within the SEU. or several questions together. "AskUser" then calls the 

The Human strategy tells the SEU to work in a human- "SendAsk" (Block 72) procedure which resides in the 

like, full interactive mode. Once a product recommendation "Interface", to perform the actual output, 

can be made, it is given immediately along with the pur- In order to output an answer (or a number of answers), the 

chasing offer with no delay. The user is asked various procedures "Recommendlnstant" (Block 70) or "Recom- 

questions followed immediately by the appropriate answer. mendAir (Block 66) respectively are invoked. The proce- 

This creates an illusion of a real, human conversation. dure "TellAllFound" (Block 68) is launched when the last 

It should be noted that the output of the question does not message should be sent, 

depend on the (physical) position of the rule in the rule base. 35 When one of the mentioned procedures of the "Interface" 

The "lookAhead" (block 30) mechanism is responsible for unit is executed, it calls the "OutputAgent" (Block 76) that 

the correct processing of the rules and for providing answers contacts the server and tells the server to send the "on the 

immediately after the corresponding questions. fly" constructed HTML page to the Internet. The method for 

In the Cruiser strategy, the SEU gathers all product contacting the server differs according to the CE software 

recommendations and purchasing suggestions and outputs 40 being used. 

them all on the user's departure from a current department/ However, "TryRecommend" (Block 46) acts differently 
session. The user sees many questions and comments with- based on the type of the business strategy that the VSD 
out getting any answers to them. The user will be "cruising" chose. If the business strategy is "human", "TryRecom- 
through the current department, responding the questions the mend" (Block 46) will call the "Recommendlnstant" (FIG. 
SEU finds necessary to ask. At the end, when and only when 45 4, Block 70). In case of any other business strategy it will 
all the rules in the current department are processed, the user save the recommendations in the virtual memory. "FireR- 
receives a list with all the answers and/or product recom- ule" will call the "DelTryRecommd" (Block 48) later, to 
mendations collected thoughout the time in the current construct a list of the recommendations saved previously, 
department. "DelTryRecommd" (Block 48) will call "RecommendAlT 
The Quick strategy stops the investigation process after 50 (Block 66) with the constructed list passed as a parameter in 
reaching the first product, or optionally and preferably order to complete the output (further information regarding 
recommends all possible products based on the existing this process can be found in the "Business strategies sup- 
information provided by the user. Naturally, the answers and ported by the SEU" section). 

purchasing offers are produced at the end of a department/ The user's responses to the SEU's queries are always 

session. The user is asked as few questions as possible, and 55 processed by the "InputAgent" (Block 74) which translates 

after the SEU finds a product recommendation it stops the the data received from the user (in the HTML format) to a 

investigation. From that point and on, the SEU processes language that the SEU understands and saves it into the 

every rule in the current department trying to reach another virtual memory for further usage by "EngineCore" (Block 

product recommendation without asking anymore questions. 42). 

The user gets a list of the product answers gathered by the 60 The components of this system operate as follows: 

SEU, ending the session in the current department. The "Recommendlnstant" (Block 70) procedure builds an 

Rules linkage and Variables: The VSD may want to answer page in HTML format. To build the header of 

operate a rule only if a certain "flag" is on or a specific the HTML page, it calls "BuildHead" procedure. 

circumstance(s) occur(s) (e.g. product "X" was purchased or The header consists of the following information: the 

not) or let the rules add information (e.g. if the eyes of the 65 name of the CGI program; reference to font and background; 

child are blue and the color of his hair is blond). The SEU a heading (such as "Welcome to Our Sit Online" or other 

knows how to deal with such techniques because it treats all messages). 
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The answer itself resides in the HTML body. The answer Humor (a set of humoristic remarks, or humoristic in 

may be a product recommendation plus purchasing offer or nature phrases to output to the user. All are combined in a 

some other kind of answer. Every kind of answer includes special database for this purpose). 

answer text. All answers which are product recommenda- Day2day (a set of slang language remarks, called day2day 

tions have "price" and "currency" variables in their descrip- 5 since it is designed to simulate simple and common daily 

tion. While such type of answer being built, the "price" language, which can also be described as a "pleasantry*'. All 

information and the 'button -checkbox' pair named "pur- are combined in a special database for this purpose), 

chase" are being attached to the dynamically built HTML Personal_preference (to specify the sales representative's 

page (supported by the "Purchase Mechanism" (Block 50)). personal preference remarks, designed to help in convincing 

It is possible for the user to purchase the product immedi- the customer regarding a decision. All these remarks 

ately by pressing the button or clicking the checkbox. The (comments) are combined in a special database for this 

button and the checkbox are together an object that makes it purpose). 

possible to control the button by the checkbox and vice Any other possible idea combined in its special database, 

versa. The comment is invoked by specifying the type of the 

The mark within the checkbox and the change of the comment followed by "=" and the number of the comment 

button's label from "purchase" to "purchased" (or any other 15 in the external library file which holds all the comments 

description desired) mean that the product is marked as database. The library consists, in fact, of a number of 

purchased. According to such marks, a list of products can different databases, one for each type of comments. This is 

be built at the end of purchasing. used to supply the user with ready made comments yet 

The "Continue" button closes the answer page in order to giving the option to add new comments, 

proceed with the SEU's session. 20 The reference is made by giving the position of the 

The header as well as the footer are constant for the entire comment in the database, 

session, but the HTML representation of the answers In the processing of this rule, the SEU asks about all the 

described above is built "on the fly" according to answer's Attribute Value pairs in the rule. If all the conditions are 

type and contents. proven, the SEU refers one of the databases in the library 

The "RecommendAll" (block 66) procedure builds an M and outputs the appropriate position entry in that database 

HTML page that consists of number of different answers. instead of asking a question 

Given a list of answers as the only parameter, it generates The commenls may be used freely thrmighout the system, 

the same HTML header as the previous function does. After exact] ^ M position inside the mles will 

hat, all the answers are output using the same algorithm ensufe ^ ^ ^ ^ tf d] ^ conditions before 

Recommendlnstant (Block 70). The user can choose what .« t in ; , K ' . . X7CT >. 

products to buy by pressing the "purchase" buttoo 30 tbem are M ff ' wluch mean * * at th f VSD m % cre , ate 

(supported by the "Purchase Mechanism" (FIG. 2, Block WI V meaningful comments mside the rules, grves the entire 

£jQ^ system even more intellectual capabilities. 

Note that there is a separate button for each and every Because the SEU treats the comments by simply gener- 

product in this page. The "Continue" button closes the page atin § output without receiving any information by this 

to allow the session to continue. 35 output (it is not a question) the comment is a condition that 

The "TellAllFound" (Block 68) procedure is only invoked is always TRUE. Thus, after the comment is output, the SEU 

at the end of the session to say "Good-bye" and to thank the continues to the next condition in the rule, 

user for the visit. This procedure sends the previously As was said before, the library might contain comments 

prepared HTML page — "Completing form". such as jokes, work playing, cynical remarks, etc. (the 

The "SendAsk" (Block 72) procedure builds different 40 "humor" section); shallow remarks such as "It is such a 

types of HTML pages for user questions and answers. lovely day" or "Really? Do you live in Israel[ It is such a 

All questions, which are stored in memory, have defini- beautiful country" and comments that are meant to convince 

tion variables such as "askStyle" and "menuStyle". "Ask- the user that he/she should buy the product: "You know, I 

Style" specifies the form of the question — a menu or a field. also bought a "brand x" screen 2 years ago and it never was 

"AskStyle" is always associated with a question. If the 45 broken!" or "When my child was 8 years old I bought her a 

question requires a 'yes' or 'no' answer — 'yesno' style is teddy bear just like that one and she always told me that it 

used. was the most beautiful present she ever received". 

"MenuStyle" defines the way the menu appears, such as As shown in FIG. 5, the comments software module 

radioboxes, checkboxes, "buttonRadio" (pair button and operates as follows. Because the comment is a part of a rule, 

radio) and "buttonCheckbox" (a button and a checkbox 50 it is encountered by "Equate" (block 44) as it processes a 

pair). The styles "buttonRadio" and "buttonCheckbox" are a rule. Thus, each time "Equate" (block 44) handles with the 

radio or a checkbox controlled by a button. They make the operator "-" it checks to see if the left side of the condition 

usage of the menu easier and more comfortable because of is a comment keyword, by calling "IsSpecial". If it is a 

the size of the button, so that the button is naturally bigger comment it invokes the "DoSpecial" mechanism which 

and easier to contact by mouse then a radio or a checkbox 55 deals with that special event. 

input. This IsSpecial routine takes the name of the query as an 

Like the other pages the output is closed by the "Con- argument and compares it to each of the keywords described 

tinue" button. above. In case of any of the keywords matches the argument 

All the described procedures remain unchanged for IS API this function returns TRUE — else it returns FALSE, 

as well as other types of CE's operating under the Internet 60 The DoSpecial (Block 78) is the mechanism that outputs 

and using HTTP protocol. the comment. Once the type of the comment is known, the 

The SEU allows the virtual sales representative to release database entry that is specified in the rule is examined (the 

comments throughout the session through a comment unit number is passed as an argument to this function). It calls 

(not shown). "OutputComment" (Block 80) in the interface shell to 

The comment structure is implemented as a condition that 65 actually send the comment to the user, 

always succeeds. In the rule base it is planted in a rule using The Preferred mechanism is a handy tool that can be used 

any one of the following keywords: by the sales representative to increase sales. This mechanism 
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allows the system designer to specify which products have The second method, Built in arithmetic functions, allows 

top priority for sale, and these products are pushed to the the user to: sum up all of the purchased products in the 

potential client first. As shown in FIG. 6, the system designer session ("SumUpAll" (FIG. 7, Block 98); sum up the 

must specify a list of product names to be taken as a top purchased products in a current department 

selling priority. The system then processes the list and tries 5 ("SumUpDepartmenf (FIG. 7, Block 98)); sum up all of the 

to direct the user to those products by asking guiding pro ducts of a given type ("SumUpProduct" (FIG. 7, Block 

questions. This feature can also be used to specify a pre-set 98)) . ^ a percentage discount ("Sys_PercentsDiscount" 

order of how products shall be sold (land of user-defined (FIG ^ Bbck 98)); and givc a coupon discount ( « Sys _ 

graomg on each product) CouponDiscount" (FIG. 7, Block 98)). 

f the work preferred is in the Rules List (Block 90), * types of arithmetic are called from within "perform" 
followed by a list of preferred products, every rule is n vj i ^\ j a n a i *u u 
obtained that includes those preferences and placed in a list, ^? block 40 > and thus are allowed onl y m the results 
and "FireRule" (FIG. 6, 2, block 32) is called to process the 01 1™ 1 *' 0 PnL . , . J e . L . . BJ . n J 
list. After that the rest of the processing is as described ™* Pars f r Structure: This kind of arithmetic ls identified 
before-i.e. invoke "FireRule" (block 32)-from the start of b V the "Perform" (block 40) by the "is" sign (FIG. 7, Block 
the Rules List (FIG. 6, Block 90). 15 between the variable and the formula instead of the "-" 
The "GetPreferred" (Block 82) function takes the prefer- si g n usually appearing between the topic/keyword and the 
ences list from the system as written in the file. Each item value in the jurisdiction of "perform" (block 40) 
on the list is processed and the following steps are per- The operation of the module is as follows. "Parameters To 
formed: Values" (FIG. 7, Block 94) is the heart of the parser. 
Walk through the Rules List (Block 90) using "GetPre- 20 "ParametersTo Values" (Block 94) is given the formula writ- 
ferredRules" (Block 84) gathering pointers (positions ten by the VSD and the variable to the left of the formula 
in the list) of every rule that leads to the preference. (the variable to store the result of the evaluation in). First, 
Create a small, temporary list of all rules which are found. the routine breaks the formula string to tokens and con- 
Pass the list to "FireRule" (FIG. 6, 2, block 32) for the rest structing a list of it. Afterwards the operator "percents_of ' 
of the process. After "FireRule" (block 32) is finished, 25 is found and converted to a standard arithmetic expression 
advance to the Next Preference (FIG. 6, Block 88) (X*Y/100). Then, another list is constructed using the fol- 
recursively, until the list of preferences is exhausted. lowing guidelines. 

"ProcessPrefList" (FIG. 6, Block 86)" is also responsible If lne token ^ a num ber or a standard symbol (+, *, \, 

for handling the tracing marker. Each time "FireRule" (FIG. ( )} add it to ^ list with no ch lf the token fa a 

2 block 32) is exited, the marker is returned to the first entry 3Q vafiable find ^ va]ue of the yariable , f {Vs a ic 

ot the new rules list tor processing (rules tor the next described 

in the system file and has not been asked yet, call 

Pr Tbe e "GetPreferredRules" (FIG. 6, Block 84) routine gets "^sk ^ser" (FIG 2, block 3 Q to ask the question. If it's not 

and processes the rules for a current preference. a topic and no value is present in the virtual memory, assume 

First, all the rules that lead to the product specified by the its value is 0. 

preference are gathered using "GetPreferred" (FIG. 6, Block 35 ™« routine the memor y to retneve the values for the 

g2). w variables. It generates questions output only in the case a 

"GetPreferred" (Block 82) uses the active memory to save va he for a current topic can not be found in the memory, 

the positions of the rules that are relevant to the current After the original list is fully processed and a new one 

preference. When this is finished (all rules have been created (containing only numbers and standard operators) 

processed), a list of those numbers is made using "GetPre- 40 the formula is evaluated by stepping through the created list. 

ferredRules" (Block 84). After building the list, "GetPre- The built-in functions are invoked whenever the "per- 

ferredRules" (Block 84) also processes it by a call to form" (FIG. 2, block 40) identifies the respective keywords 

"ProcessPrefList" (FIG. 6, Block 86). (FIG. 7, Block 100) after the "«" sign in the results of the 

The "GetPreferred" (FIG. 6, Block 82) routine looks for rule. The software module works as follows, 

a rule that has the preference in its results. "GetPreferred" 45 The "SumUpAll" (FIG. 7, Block 98) routine works with 

(FIG. 6, Block 82) is an implementation of a simple string an accumulator (previously initialized to zero) and the 

search which tries to find the string specified by the prefer- working memory directly to retrieve every product regis- 

ence in the results of a rule. tered under the handle "purchased". After a product is 

If a rule is found leading to the preference, the position is retrieved, this routine looks it up in the system file and finds 

saved in the memory. The search is repeated for each and 50 its price. The prices are summed automatically by the 

every rule until the list of the rules is exhausted. accumulator. 

The "ProcessPrefList/' (FIG. 6, Block 86) procedure also Given a department's name, the "SumUpDepartment" 

handles the following two tasks. First, it scans the memory (FIG. 7, Block 98). routine works like "SumUpAll" (FIG. 7, 

in search of previously saved rules positions. Each time it Block 98) except it retrieves from the memory only the 

finds one it retrieves the rule pointed to by the position from 55 "purchased" handle that belongs to the department specified, 

the original rules list. All the rules it finds are appended to Given a product's type which must be a "variable" that the 

a temporary list. Second, the temporary list constructed VSD uses to assign products to, the "SumUpProduct" (FIG. 

previously is passed as an argument for "FireRule" (FIG. 6, 7, Block 98) routine retrieves all information about products 

2, block 32) to process. which were purchased and which are declared in the system 

There are two ways to implement arithmetic evaluation in 60 as connected to the product's type. For example, if the 

the system, as shown in FIG. 7: following rules exist in the rule base: "if size=big and 

For the first method, the parser allows the VSD to speed»high then computer=first example, if operating 

construct formulas containing variables. The variables are system=»unix then compute r= workstation and computer- 

the topics which carry a numeric type information (such as second example" and the user decided to purchase the first 

age, price, amount . . . ). The parser works with the standard 65 example and the second example, then by invoking the 

arithmetic signs (+, *, (,), ) plus the operator "percents_ "SumUpProduct" (FIG. 7, Block 98) with the "computer" 

of. given as parameter, the prices are summed. 
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The connection is established in the system file using the 
type of a product, the "-" sign and the actual name of the 
product. 

The "Sys_PercentsDiscount" (FIG. 7, Block 98) routine 
is given the number of percents (15, 1 7, 22 ... ) and the sum S 
to deduct a discount from. 

Each of the arguments may be an actual number, a value 
or a formula. This routine will calculate the actual sum of the 
discount and reduce it from the original sum. The result is 
saved in another variable given especially for this purpose 10 
by the VSD. 

The "Sys_Coupon Discount" (FIG. 7, Block 98) is used 
in a case the VSD wishes to work with "coupon", thus this 
routine takes as arguments the sum to perform the discount 
on and the value of the coupon. Again, each of these 15 
parameters may be a number, a formula or a variable. 

The routine performs a simple reduction of the "coupon" 
from the original sum given. 

All arithmetic functions use the memory (FIG. 7, Block 
96) for writing and the result of their invocation is saved 20 
with the variables they store the results in. This information 
is saved in the same form used to save the information 
gathered from the user or "rule linkage" and may be used 
later in the rules or in the detection engine. 

Departments (see FIG. 8) are used to help the Virtual Shop 25 
Designer (VSD) to create an actual store, logically delimited 
by subjects. 

Each department consists of: the "startDep" keyword, 
which is used to mark the beginning of the department, the 
department's name; configuration to whether or not to 30 
initiate the negotiation process (negotiation=on or off); and 
a message list with optional messages the VSD wishes to 
define. If no messages are defined that list is empty by 
default. In addition, there is a list of rules which are local to 
the current department. 35 

Note: There is a possibility to pass along information 
obtained in one department to the other department. For 
example: if a product named "X" was purchased in one 
department, such information can be used in another 
department, using "rules linkage". 40 

There are 4 ways to design and manage the departments 
(see FIGS. 9, 10, 11, 12). The first way to manage the 
departments is "Spider" (FIG. 9). In this architecture there is 
one main module (FIG. 9, Block 122) which functions like 
a dispatcher, guiding the system to a different departments 45 
(FIG. 9, Block 124) with a rule derived technology (FIG. 9, 
Arrow 132). After a department is finished (the rules list is 
exhausted), the program returns immediately to the previous 
invoked department (FIG. 9, Arrow 134). See the "Depart- 
ments section" and corresponding FIG. 8 for a description of 50 
the process of going to a department and returning from one 
department to another. The departments (Block(s) 124) 
represent different rules content according to the VSD's 
design. The departments may contain links to other depart- 
ments (FIG. 9, Block(s) 126) which do not have an entrance 55 
from the main department (Block 122). 

This architecture produces a smart, sophisticated system 
giving a variety of options for touring the departments in an 
intelligent way. (For example: a client never enters the 
negotiation module if the client did not buy anything pre- 60 
viously or did not get product advice at any one of the 
departments). 

The second way to manage the departments is "Path" 
(FIG. 10). This type of e-shop has several departments (FIG. 
10, Block 128) which are not linked by rules. The "tour" is 65 
given by a path (FIG. 10, Block 116) with the departments' 
names. Each time a department is finished (Block(s) 128), 


regardless of whether or not an answer was given to or from 
the user, the next department is entered (Block(s) 128) as 
written on the path. This type of an e-shop is easier to build. 
In this type of technology the departments' messages can be 
more logical because the department (Block(s) 128) being 
left is known, as is the department (Block(s) 128) being 
entered. So that if, for example, the user enters the necklace 
department after visiting the department of earrings, an 
entrance message can be featured of the form "What are 
earrings without a matching necklace? Welcome to the 
necklace department!". 

Because there is no possibility to an automatically "fall 
back" or return from one department (Block(s) 128) to 
another, this approach is both predetermined and controlled, 
thus reducing the moments where the system's behavior is 
erroneous or illogical. 

The third way to manage the departments is "Pipe Line" 
(FIG. 11). In this approach there are several departments 
(FIG. 11, Block 126) with no dispatching mechanism. The 
logic here is very similar to the logic of the path, only here 
there must be a "main" department (FIG. 11, Block 130) and 
the other departments (FIG. 10, Block 126) are linked by 
rules (FIG. 10, Arrow 132). There is also the possibility of 
returning to a previous department. As an example, after 
department A (FIG. 11, Block 126) is finished, a return is 
made to the previous department, the "main" department 
(block 130). In order to prevent problems from arising, the 
"pipe line" approach is taken only in a case where the 
departments (FIG. 10, Block 126) connected by this archi- 
tecture are logically dependent (one department's products 
are a necessity for the other department's products). For 
example consider the following pipe lines: 

Screens-* Screen protectors-* A cable for the screen pro- 
tectors 

A VCR-*A remote control for the VCR-*A case for the 
remote control 

A table-* A tablecloth for the table-*The embroidery for 
the tablecloth 

The fourth way to manage the departments is "Path+ 
Rules" FIG. 12): This is a combination of two different 
technologies: the pipe line-derived technology (FIG. 11) and 
the pre-set path (FIG. 10) derived technology. It allows paths 
to be created (FIG. 12, Block 116), such that some depart- 
ments are connected by a path only (FIG. 12 Arrow 136) (no 
rules lead from one department to the other) (FIG. 12, Block 
128). For other departments, spontaneous linkage based on 
rules is allowed (FIG. 12, Arrow 132) which means that the 
departments linked by a path (FIG. 12, Block 128, Arrow 
136) can refer to other departments that are not part of the 
path (FIG. 12, Block 126). Those other departments (Block 
126) are linked to the "path-driven" departments (Block 
128, Arrow 136) with rules (Arrow 132). This gives a more 
intelligent system than the path (Block 116), giving various 
options for conducting the session. The "path" part (Block 
116) in it guarantees that it will fall back (Arrow 134) rarely. 

It is possible to combine and intermix the four ways to 
manage the departments in order to gain flexibility or 
features according to the need. In FIG. 9 there is an example 
of mixing the Spider with pipeline (A-*A1, E-*E1, El— > 
E2 . . . See FIG. 9, Block(s)126, 128 and Arrows 132, 134). 

As shown also in FIG. 8, the routine that launches the 
engine, "EngineCore" (FIG. 2, block 42), determines 
whether it should invoke the "path" (FIG. 8, Block 116) 
algorithm or not by checking if the keyword "departments" 
is present in the VS file. If that keyword is present, a preset 
list of departments should be entered (Block 116) and so 
"StepOver Departments" (FIG. 8, Block 112) is called to 
process that list. 
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If no such list is present, "SectionB" (FIG. 8, Block 110) to be executed if the rule is true, by using the keyword 

is invoked to process the departments. "department" followed by the "-" sign and the name of the 

The "Step Over Departments" (FIG. 8, Block 112) routine department. The system then performs a transition to the 

is used to process names of departments in the list (FIG. 8, specified department, saving the current department's name 

Block 116) passed to it as an argument. It does so by calling 5 and marker's position as a place to go back to (FIG. 8, 

"SectionA" (FIG. 8, Block 114) for each name. After "Sec- Blocks 104, 106). When the department being entered is 

tionA" (FIG. 8, Block 114) is finished processing the finished, the program goes back to the previous department 

department, the next department in the list is considered. without losing any information gathered previously. Such a 

When the list is exhausted, the program is finished. transition is performed by one of the "Perform" (FIG. 2, 

Tliis routine is using the memory to retrieve any infor- 10 block 40) routines as follows: 

mation regarding the position in the VS. First, identify the department to be entered. 

This routine is necessary due to the specification of the If the current department's messages list contains a 

CGI, in that the session consists of exiting and re-entering "backlnAMinute" message — output it now using "Out- 

the program. Each time "StepOverDepartments" (FIG. 8, putComment" (FIG. 5, Block 80). 

Block 112) finds a "position marker" it passes the informa- 15 Save the current department's information with the handle 

tion consisting of current department name and the rule "previous". 

number in that department as an arguments to "Section A" Generate a partial department's information constructed 

(FIG. 8, Block 114), By default those arguments are instan- of the department's name and the position set to "1". After 

tiated to "main" for department name and "1" for the rule that, "Perform" (FIG. 2, block 40) calls the "SectionA" 

number. 20 (FIG. 8, Block 114) or "SectionB" (FIG. 8, Block 110) to 

The "SectionA" (FIG. 8, Block 114) was written to be continue the construction of the department's information, 

called from "StepOverDepartments" (FIG. 8, Block 112). based upon whether or not the keyword "departments" 

That is why it does not use the working memory for reading followed by a list of department names (FIG. 8, Block 116) 

or writing (compare with "SectionB" (FIG. 8, Block 110) is present in the VS. 

below). 25 Another department can also be entered with the "lookA- 

In the operation of "SectionA" (Block 114), first the head" (FIG. 2, block 30) mechanism, 

department's information is allocated in the VS file using In that case, the status is saved under the name "lookA- 

"startDep". Then the departments' rules list is retrieved and head" (block 30). The meaning of this is that both "FireR- 

passed to "ProcessRulesList" (FIG. 2, block 38) for pro- ule" (FIG. 2, block 32) and "FireNextRule" (FIG. 2, block 

cessing. After "SectionA" (FIG. 8, Block 114) is finished, 30 34) are moved to the new department's location, 

the program returns to "StepOverDepartments" (FIG. 8, Returning from a department to another department is 

Block 112) which then permits access to the next department relevant only for two departments linked by a rule and not 

in the list specified in the VS file. If the current department's a path (FIG. 8, Blocks 104, 106). When 2 departments are 

messages list contains an "entrance" message this routine written in a preset list (FIG. 8, Block 116), such a return is 

outputs the entrance message by a call to "OutputComment" 35 not possible. 

(FIG. 5, Block 80). When department A refers to department B, the system 

The "SectionB" (FIG. 8, Block 110) routine is invoked in returns to department A at the same position when the 

every VS design except the "path" that was described above. department was exited (FIG. 8, Blocks 104, 106). For this, 

It is responsible for saving tbe initialization of the param- 2 routines are used: 

eters that are specified in the department, such as negotiation 40 The "BackADep" (FIG. 8, block 102) routine is called 

(on or off) and the business strategy (human, quick or from the third part of "ProcessRulesList" (FIG. 2, block 38). 

cruiser), updating the trace marker for the department and Once the end of a department is reached, this routine does 

outputting the entrance message for the department. Thus, it the following: 

uses the working memory directly plus is passes all the Output the appropriate message for the department, pass- 
necessary information about the department (rules' list, 45 ing the name and messages list to "OutputTheRightMes- 
messages list, current position (rule number) and the depart- sage" (FIG. 16, Block 184). 

ment's name) to "ProcessRulesList" (FIG. 2, block 38). Invoke the "Go_Back" (FIG. 8, Block 108) routine to 

If information was saved in the memory previously perform the exchange between the current and the "previ- 

regarding the current department and position, "SectionB" ous" department info in the working memory. 

(FIG. 8, Block 110) does not overwrite the information. 50 Retrieve the current department information (after the 

Instead, it reads that information from the memory and pass exchange). 

the information along to "ProcessRulesList" (FIG. 2, block Invoke "FireRule" (block 32) to process the rest of the 

38) as an argument. If no such information exists, "Sec- rules in the department. 

tionB" (Block 110) looks up the rules list of the "main" Unlike the move to another department done according to 

department to pass along to "ProcessRulesList" (block 38) 55 an appropriate rule (which means it is written explicitly in 

and saves that information in the memory for next time (for the VS), the process of returning back from a department is 

example of the process see FIG. 8, Block 104). done automatically when the department is finished, such 

Because only one description of the department's infor- that the rules list is exhausted. Thus, this process is marked 

mation can be present in the memory, either "SectionB" with a dashsed arrow (FIG. 8, Arrow 118), unlike the process 

(FIG. 8, Block 110) or "StepOverDepartments" (FIG. 8, 60 of moving to another department which is marked by a solid 

Block 112) must clean up all descriptive information from arrow (FIG. 8, Arrow 120). 

the stack before writing any department's description to it. The "Go Jack" (FIG. 8, Block 108) function does a pure 

The department's information consists of the 5 parts memory manipulation and thus produces no visible output. 

described in the beginning plus the trace marker (the number First the memory is read to find the previous department's 

of the rule currently being processed). 65 information using the handle "previous". 

The VSD may specify a department reference in the "Go_Back" (FIG. 8, Block 108) also updates the trace 

"then" part of a department rule as a result or consequence marker according to tbe status when the department was left. 
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If it is "lookAhead" (FIG. 2, block 30) status, then the 
program returns to the same rule. If it is not, the program 
returns to the rule succeeding that rule. 

The current department information including all tracing 
signs, such as "was" is totally abolished. Instead, the "new" s 
department information is given, which was the same infor- 
mation received under the handle "previous". 

It is also up to "Go_Back" (FIG. 8, Block 108) to free the 
"previous" handle regarding the department returned to. 

"Go_Back" (FIG. 8, Block 108) returns no value to the 10 
calling routine assuming all the necessary information is 
read from the memory. 

The mechanism for offering alternatives attempts to bar- 
gain with the potential client and tries to make a sale when 
the user visited a department and got no answer, meaning 15 
that no products were available for this kind of demand. 

The system always remembers the questions it asked and 
the responses given by the user. 

In a case no product is available for a client according to 
the client request, the mechanism attempts to persuade the 20 
client to compromise about one or more topics to attempt to 
complete a sale of some product. 

Preferably, the mechanism can be turned on and off from 
within each department. 

The maximum number of attributes that differ from the 25 
original request is defined by the VSD. 

The mechanism naturally integrates with the normal flow 
of the session. 

The mechanism quits after a certain amount of questions 
or after a product is purchased. 30 

The "line"s consist of the number of the rule and a list of 
conditions — flags pairs where the flags are 0 — for a condi- 
tion that was not fulfilled and 1 for conditions that were 
fulfilled. 

The "goodLines" on the other hand, contain only a list of 35 
conditions that were not fulfilled (the conditions with the 0 
flags), the number of the rule and the exact number of the 
conditions that were not fulfilled. 

The operation of the mechanism for offering alternatives 
is described with reference to FIG. 13. The mechanism is *o 
invoked (FIG. 13, Block 160) from "ProcessRulesList" 
(FIG. 13, Block 38) using "BuildTable" (FIG. 13, Block 
138). This routine creates the table file if the table file does 
not exist. If it exists this routine simply opens it for reading. 
Then "ProcessRuledList" (Block 38) invokes the "Loop" 45 
(FIG. 13, Block 140) mechanism to do the work. 

Given a department's name and the rules list, the "Build- 
Table" (FIG. 13, Block 138) routine builds a table file using 
"OpenTableFile" (FIG. 13, Block 15(T) which consists of 
lines marked with "fine" which hold the satisfied and not 50 
satisfied conditions for each and every rule, and other lines 
marked with "goodLine" that carry the information about 
those the rules which are relevant to the negotiation. The 
writing to the file is done by "WriteTableFile" (FIG. 13, 
Block 158). This information must consist of rules that meet 55 
the following demands: a. These rules must have all their 
attributes declared as negotiable, b. The maximum number 
of conditions that were not fulfilled must be less or equal to 
X, where X is a constant number defined either by the 
detection engine or directly from the c-shop's configuration 60 
file. The "gatherRuleStatistics" module is called (FIG. 13, 
Block 154) to satisfy these demands: 

First, each and every rule in the current department is 
processed, checking which conditions were fulfilled and 
which were not fulfilled in the current session. 65 

Then the "line" entries are constructed and written to a file 
using "WriteTableFile" (FIG. 13, Block 158). The lines are 


sorted to "goodLines" according to the number of unfulfilled 
conditions in those rules and whether or not a "line" consists 
only of negotiable topics. If at least one topic in a "line" is 
not negotiable, a negotiation on this "line" is not possible. 

The "goodLine"S also specify the exact number of unful- 
filled conditions for each rule. 

The "WriteTableFile" (FIG. 13, Block 158) writes both 
"line" entries and "goodLine" entries to the same file. 

To sort all the "line"s to "goodLines", statistics are 
gathered on the "line" to see how many unfulfilled condi- 
tions they have. 

The program starts by looking at the "maxZeroes" 
information — which specify the maximum number of dis- 
proven conditions a "line" can have so it will be treated as 
"goodLine". This number is set by the VSD when the VS is 
built, however, it may be altered by the DE throughout the 
session. 

A "line" will be considered as "goodLine" if and only if 
the number of conditions that were not fulfilled in this line 
is less or equal to "maxZeroes". If the number of conditions 
that were not fulfilled in this line is less or equal to 
"maxZeroes", "GatherRuleStatistics" (FIG. 13, Block 154) 
will also create a "goodLine" which will contain only the 
conditions that were not fulfilled in the current line. If the 
number of unfulfilled conditions is greater than 
"maxZeroes", the current line is skipped and the program 
continues checking the next line. 

If the constant "maxZeroes" was not specified in the VSD 
or set by the detection engine, the default is preferably 
considered to be 3. 

The "Loop" (FIG. 13, Block 140) procedure is where 
negotiation actually occurs. 

The method is to process N "goodLines" where N is 
configurable either by the VSD, or by the detection engine. 

This is a "smart" processing with a priority — from the 
"best" option to the "worst" option: e.g. the "goodLine" 
which has only one unfulfilled condition vs. a "goodLine" 
which has all N unfulfilled conditions. To do so, "StartPush- 
ing" (FIG. 13, Block 140) routine is called, but first the flag 
"question_out" is turned on, so no more questions are asked 
during the process. 

"Loop" (FIG. 13, Block 140) uses the memory for read- 
ing. It checks the memory from time to time looking for an 
information saved under the handle "negotiated". Once it 
finds such information, it looks for the matching user's 
answer. If the answer is "yes" (e.g. the user was asked a 
question of the type "Do you agree to compromise and agree 
the color of the diamond would be yellow?" and answered 
"yes" to it), "Loop" (FIG. 13, Block 140) puts the informa- 
tion received by the negotiation process as if it was received 
by a normal process, and invoke "FireNextRule" (FIG. 2, 
block 34) to process the rules again with the extra informa- 
tion supplied (in the memory). 

The "StartPushing" (FIG. 13, Block 140) routine executes 
for a maximum times of "productsToNegotiate" which is a 
constant number similar by definition and handling to 
"maxZeroes". The routine specifies the maximum of prod- 
ucts which are allowed to be pushed, and thus, the maximum 
number of "goodLines" which the program is allowed to 
process. 

This procedure ("StartPushing" (FIG. 13, Block 140) 
gives the "grading", such that the program begins looking 
for a "goodLine" with 1 unfulfilled condition. 

When such a "goodLine" is found, the program initiates 
"NegotiateOnLine2" (FIG. 13, Block 144), and increments 
the iterations counter (FIG. 13, block 152) using "Negotia- 
teOnLine3" (FIG. 13, Block 146). 
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After "NegotiateOnLine2" (FIG. 13, Block 144) is FIG. 14 shows an illustrative embodiment of the Financial 

finished, and there is no product available for the user yet, Purchase Manager (FPM). The FPM provides financial 

the processed "goodline" is deleted and the program tries to service of purchases. It enables the display of the full list of 

find another "goodline" that also has one unfulfilled condi- goods bought, their prices, any discount and the total amount 

tion. If the program could not find a "goodline" that has only 5 which the client should pay. 

one unfulfilled condition, it looks for a line which has 2 The client has the ability to change the quantity of chosen 

unfulfilled conditions and so on. All in all 2 indexes are used, goods and recalculate the sum of discount and the total price 

one for the total amount of the "goodLines" already according to the changed quantity. 

processed, and the other for the current amount of unfulfilled All the processes of the FPM are implemented as a 

conditions being processed. The procedure stops execution 10 specific part of the "Perform" (FIG. 2, block 40) unit for 

and exits immediately if one of the following events occurs. credit card charging. 

First, if the number of "goodLine"s processed exceeds the For mathematical calculations of total sum and discount, 

limit set by "productsToNegotiate", or alternatively, if the the "SumUpAlT and "SysJercentsDiscount" (FIG. 14, 

number of unfulfilled conditions being examined exceeds Block 164; FIG. 7, Block 98) routines are used accordingly, 

the limit set by "maxZeroes". 15 They are both launched from "ReportBasket" (FIG. 14, 

"StartPushing" (FIG. 13, Block 140) stores the two inner Block 162), a routine that is responsible for displaying the 

indexes in the virtual memory in order to prevent data loss. list of the purchased goods. 

The "NegotiateOnLine2" (FIG. 13, Block 142) routine The operation of these procedures are described with 

takes as an argument the "goodline" to process. It calls reference to FIG. 14. Before displaying list of purchased 

"NegotiateOnLinel" (FIG. 13, Block 144), which outputs 20 goods, the total price and discount are calculated. A list of 

questions to the user regarding the appropriate topics by goods is displayed in a table with a quantity field for each 

using "AskUserNegotiate" (FIG. 13, Block 150). The mod- row (product) allowing the user to change the number of 

ule performs a local "rules discard" mechanism after each units to be ordered separately for every product, 

part of the current "goodline" was negotiated but before the The "ReportBasket" (FIG. 14, Block 162) routine starts 

user's answer is checked. If the answer is "no", the "good- 25 by skimming the memory in search of "purchased" handles. 

Line" is deleted entirely and the program exits. Before As it was described in "The interface to the SEU" section of 

exiting the program reads the current number of iterations this document, the "purchased" handle stands for products 

(the "goodLines" which were processed) from the memory that were purchased during the session, 

and increments this number (FIG. 13, Block 152). Once it finds such a handle, "ReportBasket" (FIG. 14. 

The "AskUserNegotiate" (FIG. 13, Block 150) procedure 30 Block 162) extracts the product's name and refers to the VS 

outputs specific "yes or no" questions for offering alterna- file. 

tives according to a factor described as a "negotiating In the VS file, "ReportBasket" (FIG. 14, Block 162) finds 

factor", such as the price. the product by the name and finds the price in the product's 

The VSD may specify a special question in the description description/database field. The product's name and price are 

of the topic in the VS file, such as "You know, the color you 35 saved as a list entry. 

are asking for is currently unavailable, but we have so many After "ReportBasket" (FIG. 14, Block 162) has found and 

other beautiful colors. Maybe you would like . . . ". The rest processed every "purchased" handle, it generates a HTML 

of the sentence is constructed by this routine on the fly, page with a table. The rows of the table consist of the 

according to the value that the specific rule expects, such as generated list's entries plus one more column for the quan- 

color, brand name, size, etc. 40 tity field. The value of the field is also read from the virtual 

If the VSD chose not to specify a special question, there memory and is preferably "1" by default. Two buttons, 

is preferably a default text of the type "Would you "Continue" and "Recalculate" are displayed on the GUI and 

agree<Topic> would be <Value>", where the topic is the the output finishes. 

current topic that is passed to this procedure as an argument. The identity of the field corresponding to each product is 

The value is the value needed to equate with the topic in 45 known because the field's name in the HTML generated 

order to perform the rule which is specified by the current source it receives the name of the product it responds to. 

"goodLine". The user's input is preferably checked to avoid negative 

As an alternative and preferable file handing mechanism, numbers, fractions or letters. If the user uses one or more 

the file for dumping the "lines" and "goodLines" could be types of invalid input as described above, a message is 

created under the department's name, which would increase 50 shown, saying that only positive, whole numbers are 

the ease of finding and manipulating the different routines allowed. 

participating in the mechanism. The user is preferably only able to press the 'Continue' 

The handle obtained is saved in the memory under the button after pressing 'Recalculate' if the quantity has 

memory section "system". changed. Pressing the "Recalculate" button starts the pro- 

When the file needs to be opened subsequently, the 55 cess from the beginning (FIG. 14, Block 166), so that the 

previously saved handle is used to open the file. Then all the "SumUpAll" (FIG. 14, Block 164) routine is invoked fol- 

information is written to the virtual memory, using the lowed by "Sys__PercentsDiscount" (FIG. 14, Block 164) 

"OpenTableFile" (FIG. 13, Block 156) routine. and/or "Sys_CouponDiscount" (FIG. 14, Block 164) with 

For writing the "WriteTableFile" (FIG. 13, Block 158) the new quantities so to the total price is obtained and the 

routine is used, which receives the department's name as its 60 discount updated. The results of the inference resides in a 

only parameter. new HTML page created by "ReportBasket" (FIG. 14, Block 

The routine opens a file under that name and writes to 162) as it repeats the whole process again, 

each and every piece of information to the file regarding the Because the new quantities reside in the virtual memory 

"line"s and the "goodlines". The "line"s and the "good- with the name of the product they refer to, the new page 

Lines" have already been constructed in another routine, so 65 includes the new quantities as the appropriate fields' values, 

all "WriteTableFile" (FIG. 13, Block 158) must do is transit Pressing the "Continue" button (FIG. 14, Block 170) 

them in the appropriate order to the file. takes the user to the credit card charge process (FIG. 14, 
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Block 168). The Financial Purchase Management unit may such as telephone number and E-mail address. If not all the 

include the credit card charge unit, or else alternatively and necessary data was filled in, an error message is sent using 

preferably the units can be separate but in communication "OutputComment" (FIG. 15, Block 80) and the CCC pro- 

with each other. cess restarts. 

The Credit Card Charge (CCC) process enables safe S The next test performed by "IsNumber" (FIG. 15, Block 
transfer of credit card numbers through the Internet. The 178) determines whether the received portion of the credit 
security is provided by transferring the number with a card number is a valid number. If any non-numerical char- 
plurality of separate transactions, in which the number is acters are present in the received part of credit card number, 
divided into a plurality of portions, and each portion is the number is invalid. If the number is invalid, an error 
included in a separate packet for separate transmission 10 message is sent using "OutputComment" (FIG. 15, Block 
through the Internet. The user preferably decides how many 80) and the CCC process restarts. If the received part of 
digits from the credit card number are transferred at any credit card number is valid, the part is appended to the 
transaction. The CCC process at the client side has the previously received parts using string concatenation, in 
following steps. First, the user is prompted to fill in a form order to construct the whole number. The "f_charge" van- 
including the shipping and credit card data. Next, at least one 15 able serves for credit card number collection, 
digit of the credit card number is entered in the input field. The third test performed by "CheckDifference" (FIG. 15, 
The user than presses the "Continue" button to send the Block 180) checks whether the whole credit card number 
form. was received. The decision is made by matching the 

On the next screen the user is prompted to input at least received number length with a previously stored constant 

one more digit and press the "Continue" button. This process 20 number which is a length of every known type of credit card 

is continued until the whole number is entered. The number number. "CheckDifference" (FIG. 15, Block 180) performs 

of figures left to input is displayed. all of the length tests. 

After the entire number is received, determined by the The "CheckDifference" (FIG. 15, Block 180) routine is 

server according to the type of the credit card and the called from "TestData" (FIG. 15, Block 176) to calculate the 

number of expected digits of the credit card number, the user 25 difference between the valid length of the given credit card 

is prompted that the process finished successfully. number and the length of the received data. There are two 

If characters other then numbers were entered or extra purposes for this calculation, showing the client how many 

numbers were entered it is considered to be an error and the digits are left to input and checking if the length of the input 

user is informed of the mistake. The process is interrupted number is larger than it should be. 

and preferably must start all over again. 30 This function simply performs a subtraction between the 

CCC process implemented as a specific part of the "Per- length of the number as it should be (a constant) and the 

form" (FIG. 2, block 40) function. length of the number that was input. The variable "left" 

Note: The client decides how many digits to put in each serves to store the difference. If the entire number was not 

form. The system generates as many forms as needed to yet received, "CheckDifference" (FIG. 15, Block 180) 

charge the complete credit card number. 35 returns the difference and "TestData" (FIG. 15, Block 176) 

The operation of the credit card charge unit is explained prompts the client using "SendAsk" (FIG. 15, Block 72) to 

with reference to FIG. 15. input the next part. "TestData" (FIG. 15, Block 176) shows 

The same "Perform" (FIG. 2, block 40) function is called the user how many digits are left to input, using the value 

several times during CCC process. However the behavior is that was calculated in "CheckDifference" (FIG. 15, Block 

different depending upon the CCC process state. In order to 40 180). 

indicate the state, appropriate flags are used. While checking the entire number received, the situation 

When entering the "Perform" (block 40) function, first the of extra data input is being tested as well. In the case that 

flag "ibeginning_of_charge" is tested (FIG. 15, Block extra numbers were entered "CheckDifference" (FIG. 15, 

172). This testing is being done in order to send the first Block 180) returns a negative difference. "TestData" (FIG. 

(prepared) HTML page at the beginning of CCC process 45 15, Block 176) informs the user about the mistake and the 

with the use of "HTMLSend" (FIG. 15, Block 174). If it is CCC process is restarted. If the input is of a valid length, 

the beginning of the CCC process, the first (prepared) "CheckDifference" (FIG. 15, Block 180) returns 0 and 

HTML form is sent using "HTMLSend" (FIG. 15, Block "TestData" (FIG. 15, Block 176) notifies the client about a 

172). The difference between the first and the following successful transfer using "OutputComment" (FIG. 15, Block 

pages is that the first page exists as a file in the disk while 50 80). 

the others are created dynamically. The first form is being After the numbers have been received, the credit card 

simply read from the disk and sent to the user by the number is optionally encoded and stored using "SaveC- 

"Interface" module using "HTMLSend" (FIG. 15, Block CNumber" (FIG. 15, Block 178) along with the user's 

172). Other pages are built "on the fly" by the same private information for further processing. Thus, if encoding 

"Interface to the SEU", that has functions for building 55 is used the whole credit card number exists as a whole only 

number types of HTML forms. The "SendAsk" (FIG, 15, for a rather short period of time. 
Block 72) function is used for prompting to input numbers Encoding is performed by the following steps: 
and "OutputComment" (FIG. 15, Block 80) for reporting The number being encoded is divided into several parts, 
state (errors and success). The first form that is sent by Every part is encrypted using an arithmetic or a logic 

"HTMLSend" (FIG. 15, Block 174) includes fields for 60 operation with the appropriate part of the key. Alternatively 

name, address, telephone number of client, credit card type and preferably, each part is encrypted substantially before 

and first part of credit card number. being transmitted from the first computer to the second 

The "TestData" routine (FIG. 15, Block 176) tests the computer. During encryption, the length of the result string 

received data and indicates whether the important client data may overflow or underflow the length of the part that was 

was input by the client into the first page and was success- 65 encrypted. To recognize this, "situation flags" are set such as 

fully received by server. All fields in the first page must be 'overflow', 'underflow' or 'no overflow' for every part that 

filled in, preferably excluding some non-mandatory fields is being encrypted. 
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The credit card number is then reassembled from the parts 
with the additional flags. The process is as follows. 

First, the number, as well as the key, is converted to a 
string. Then, the "encrypt" routine is invoked. 

The first few characters of the number are taken and 5 
converted to integer. The same is done with the first part of 
the key. The arithmetic or logic operation with these two 
integers is performed. If overflow or underflow occur then 
the appropriate 'overflow' or 'underflow' flag is set. 

Note: the actual representation of the flags consists of 10 
three parts: the first holds, as was said previously, the 
"overflow" or "no overflow" information about the part of 
the number it corresponds to. The second part of the flag 
carries information about the number of digits that the 
according part of the number contains. 15 

In case overflow or underflow did occur, the third part of 
the flag holds the extra (or missing) number of digits which 
were added (or subtracted) as a direct results of the encoding 
operation. This number is evaluated by subtracting the 
length of the string before encryption from the length of the 20 
string after encryption. 

The initial value of the flags is set to "no overflow" for the 
first part and "0" for the other two parts. 

The second part of the number is taken and converted to 
an integer. The same is done with the second part of the key. 25 
The arithmetic or logic operation with these two integers is 
performed. If overflow occurs the appropriate 'overflow' 
flag is set. 

The same conversions and operations are performed with 
every part of the number and the corresponding part of the 30 
key. 

After that, all encrypted parts of the number are converted 
to strings and packed to a whole, encoded string, along with 
their corresponding flags. 

• The resulted string is stored in an external file along with 35 
the rest of the client's personal data (name, last name, etc.). 

The decoder is a separate program, isolated from the 
Encode program in order to avoid fraud and theft. It can be 
located in a different server, URL, company, network or the 
like. 40 

One implementation can be to locate the decoder program 
at the credit card company, so the card number is not 
available even to the VSD. The VSD receives the number 
only as a code representation while the true card number 
stays at the financial institution. 45 

The decoder takes the string that represents the decoded 
credit card number, divides it into the parts which are set by 
the flags, converts the parts to integers, takes associated 
parts of the key, converts them to integers and performs the 
opposite arithmetic or logic operation with each part-key 50 
pair. 

After performing the operation with all pairs, the decoder 
packs them all to create the decoded number. The Decoder 
takes the encoded string as the first and only parameter. The 
Decoder starts by extracting the flags' sub-string from the 55 
string. Then, by the value of the second part of the flag, the 
decoder collects the appropriate number of digits from the 
number and the key. 

The sub-strings formed in branch 1 are transformed to 
integers. 60 

The opposite arithmetic/logic operation is performed on 
these two integers, (instead of "+" there will be used "-" 
here, instead "*" used in the encoder, here shall be used "\" 
and so on). 

The result is saved in a container. 65 
Steps 1-3 are performed until the entire number is pro- 
cessed. 


The list that was constructed from all the parts (branch 4) 
is assembled as a string. 

The Department Messages are described with regard to 
FIG. 16. Every Department may contain a message list (FIG. 
16, Block 182) which may specify 5 diiferent types of 
messages (described below). This messages are of the form: 

<Message keyword>=<Message test> 

where Message keyword is one of the "entranceMsg" 
(FIG. 16, inside Block 182), "failureMsg" (FIG. 16, inside 
Block 182), "exitMsg" (FIG. 16, inside Block 182), "non- 
purchasedMsg" (FIG. 16, inside Block 182) or "backl- 
nAMinuteMsg" (FIG. 16, inside Block 182) and the Mes- 
sage text is some lines of text the e-shop designer entered. 

Not all five types of messages must be defined. Indeed, the 
messages might not be defined at all, if the VSD does not 
wish to let the user know which department is being 
accessed. These messages are configurable for each depart- 
ment separately. 

There are basically 2 groups of messages : messages 
given upon entering a department and messages given while 
exiting. Those messages are handled differently. The pre- 
department messages work as follows. The message is 
handled by the routine that handles the entrance to the 
department. 

It can be either "SectionA" (FIG. 16, Block 114) or 
"SectionB" (FIG. 16, Block 110), depending on the virtual 
shop design. 

The message is retrieved from the messages list using the 
keyword "entranceMsg" (FIG. 16, inside Block 182). The 
message string is sent using the routine "OutputComment" 
(FIG. 16, Block 80), once the department which is about to 
be entered is identified using "startDep". 

The post-department messages work as follows. There are 
several ways to leave a department. For example, if all rules 
are processed but there was no product to recommend — give 
a "failure message" (FIG. 16, inside Block 182). 

If all rules are processed and one or more recommenda- 
tions were given but the product(s) was not purchased — give 
a "non-purchased" message (FIG. 16, inside Block 182). 

If all rules are processed and eventually the user did buy 
something — give an "exit" message (FIG, 16, inside Block 
182). 

If in the middle of rules processing, go to another 
department — give a "backlnAMinute" message (FIG. 16, 
inside Block 182). 

The procedures operate as follows. 

The first 3 messages in the post-department messages are 
output using "OutputTheRightMessage" (FIG. 16, Block 
184) routine. 

The "OutputTheRightMessage" (FIG. 16, Block 184) 
routine is merely checks what message should be outputted 
and outputs the message using "OutputComment" (FIG. 16, 
Block 80). "OutputTheRightMessage" (FIG. 16, Block 184) 
is called from "BackADep" (FIG. 16, Block 102), which 
means that the messages are given when about to return to 
the previous department. 

The "failure" message (FIG. 16, inside Block 182) is 
output if the flag "has_answer" is turned off for the current 
department (this flag is turned 'on' by "TryRecommend" 
(FIG. 2, Block 46) routine). 

The "exit" message is output if the flag "purchased" is 
turned on for the current department. 

The "has_answer" flag does not need to be checked, 
because purchasing can't be done without receiving a prod- 
uct recommendation first. 

The "non-purchased" message is given when the flag 
"has_answer" is on but the flag "purchased" is off. 
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The "backlnAMinute" message (FIG. 16, inside Block to him for a year. So think hard before you tell me: what 

182) is handled in the "Perform" (FIG. 2, block 40) routine. color do you want your car to be?" 

When "Perform" (block 40) encounters the keyword After that, the builder needs to know the appropriate 

"department" in the results of the rule it has to perform— it answers to the issues, the answers which lead the sales 

retrieves the "backlnAMinute" message (inside Block 182) 5 representative to recommend the current product. For 

from the current department messages list (FIG. 16, Block example, if the issues are: "color, speed, acceleration" and 

182) and send it using "OutputComment" (FIG. 16, Block ^ P rodu <* » "Brand x , > the sales representative 

80). This message is sent before leaping to the next depart- recommends that brand only if the color is black, gray or 

m ^ nt white and the speed is very high and the acceleration is very 

~, " , ... c . c e , , , . , . rrr^ _ fast. So the next builder's question is "When you ask me 

The descripUcm of the E-Shop builder is shown ,n FIG. ,0 „ wha( ^ dQ ymj wam ^ caf ^ be? „ ^ should , 

' _ . - , . * , answer you so youTl recommend a Brand X car?" and the 

^ e i" Sh ? ) l$ 3 S ,° ftWa L e P/ cka g e ^n dlv L ldu f^ d f° r ««* V SD will input all the colors wanted here, for instance "gray 

VSD. Therefore, it has to be designed by the VSD and added or bi ac k or white" 

to the SEU in order to form a complete, working system. Mtcr the is^'for t he current product are processed in 

The E-shop builder is structured as a unit that helps the 15 mat way, the recommendation text is given. The recommen- 

VSD build the e-shop. It does so by interrogating the VSD ^ at j OD text ^ by the SEU to tell the user the recom- 

about the products, the selling methods and strategies. mended product. After the user is asked about the color, the 

Everything is done in the form of an interactive interview speed and the acceleration and respond to the questions 

with the VSD. The trend is to work on one product at a accordingly to what the VSD expected, the user gets this 

time — asking about the usual topics usually considered 20 recommendation text. The builder asks the VSD how to 

during the sale of the product. The purpose of this session is recommend the product to the user. A possible answer could 

to teach the Internet Sales Representative regarding the be "Brand X is the perfect choice for people who like big, 

shop, the products, the sales strategy, the negotiations and fast cars. We have a special Brand X sale this month, so if 

every other component the 'human' sales representative you buy one now, youTl get a 10% discount!" 

would like to teach to the Internet Sales Representative. 25 The process continues until all the departments are built, 

However, it should be noted that the E-shop builder of the along with the topics, options, answers and so on. This 

present invention could also be used to build substantially indicates the end of the first pass on the creation of the 

any rules-based system based on questions asked of, and E-shop. 

answers obtained from, a live human being. The second pass deals with the different business 

The procedure operates as follows. The process begins 30 strategies, the offering alternatives and the preferred prod- 

with greeting the sales representative and an explanation of ucts for each department. The builder go through the list of 

the process, in a form of "Hello, welcome to the E-Shop departments by their names asking the user to choose the 

builder. We will now build you an electronic shop which will business strategy for the department. Some possible busi- 

consist of departments, shelves, products, a cash register and ness strategies are: human, quick, cruiser, as described 

salesmen as you would like to see it. All you have to do is 35 above. 

to answer the questions I will ask you." After selecting the business strategy, the builder asks the 

After that, the session begins. The builder asks about the VSD about the products to try to sell first in the current 

departments first. Departments are defined as product lines, department. The VSD may specify product names in the 

much like real departments, so a possible answer to the form of "Brand X, Brand Y, Brand Z". This list is written to 

question "which departments do you want?" may be 40 the e-shop file as "preferred" for the current department. If 

"computers, printers, modems". the VSD supplies no answer to this question but just 

The builder then concentrates on each department indicates acceptance, the builder will continue the investi- 

separately, asking the VSD which products are to be sold in gation and no "preferred" brands are written to the file, 

each department. For example, when the VSD is asked As for the offering alternatives, the builder asks the VSD 

"What products do you want to sell in the printers 45 only one question regarding all the topics in the department: 

department?", the answer may be "Epson 400, Epson600, "Click on the topics you want from the list below to specify 

Epson800, HPL6L". that the topic is negotiable" followed by a list box that 

After receiving the information about the products, the contains all the topics that were input throughout the session, 

builder starts asking questions about about each product If the VSD selects the topic in the list box, the topic changes 

separately. The VSD is asked about the subjects usually 50 color and is treated by the builder as negotiable. The word 

considered while selling the current product. The term "negotiable" is written in the topic's description in the VS 

"subjects" refers to issues which are crucial to the selling file. The same is done for the department to specify 

process. "negotiation=on" or "off" in the department's description. 

For example, if cars are sold then the acceleration of the The third pass is used to specify the department architec- 

car, the make and model, the number of passengers, even the 55 ture (spider, path, pipe line, etc.). 

color is important to know before any car is recommended. The builder helps the VSD to create an appropriate design 

So the VSD is prompted to enter those topics and the input by giving directions based on the amount of the rules, the 

may be something like "color, model, acceleration, perfor- industry the VSD is dealing with and other criteria. In the 

mance" and the like. fourth pass the VSD is guided through the construction of 

Once the issues are known, the builder asks for the text of 60 the "cash register" department and the decision of which 

the questions. That text is used by the SEU later to ask about department is the "main" department. The last pass before 

the issue. The builder asks "How would you ask your client adding graphics to the VS is the pass where the builder 

what color he or she wants?". The VSD writes the question simulates the session by reading the rules and outputting the 

to ask, using imagination and creativity. For instance, an appropriate questions. In this process the VSD may add the 

interesting question may look like this: 65 comments by clicking the "Add comment" button in the 

"The color of the car is very important, you know. My session's window instead of clicking the "OK" button which 

cousin once bought a beige limousine and no one has spoken launches the next screen (question). 
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The process functions are described with regard to FIG. in the "wizlib" and a list of replacements to be used instead 
17. of the text inside the "replacement tags". 

The "ProcessDepartments" (FIG. 17, Block 202) routine First, a random number function is run, giving as a seed 
uses "OutputComboQuery" (FIG. 17, Block 186) to get the the number of lines in the section specified in the "wizlib" 

departments the VSD wants to put in the virtual shop. It 5 by the keyword, to avoid repeating the same question several 
simple outputs the question and reads a string of the depart- times in a row 

ments' names separated by commas. It calls "ProcessProd- Nextj me line specifie d by the number that the random 

ucts" (FIG 17 J31ock 188) to gather information about the rctumed is extractcd , and thc following operations 

products the VSD has in each department. nprfhrmeH 

The"ProcessProducts"(HG. 17, Block 188) routine reads 1rt J™™„' thp . trInfJ fn , , ict nf wnr - 

c . « ,\ C n * . 11 • .u * 10 rirst, convert the string to a list ot words, 

a stnng of products the VSD wants to sell m the current KT ; c , 4l _ , f4 * A nt „ x , , . 4 . iC A , 

department and create a list of them. After that, this proce- Next > fiad ^ left mark " u P ta S C"< ) and delete it from the 

dure goes through the list, asking the user to enter the topics. ' , , _ „ . , , _ , , , 

It calls "ProcessAllTopics" (FIG. 17, Block 192) to read, Replace the following text with the first element of the list 

create a list out of and process the topics the VSD wants to of replacements given as a parameter. 

talk about in the process of selling each product. In the end 15 Delete the nght mark-up tag (">"). 

of it all, it builds the rule pattern and write it to the virtual Delete tDe first element in the list of replacements, making 

memory directly (FIG. 17, Block 190). It also creates the the second element the first element for the next time. 

appropriate pattern for product recommendation in SL for- The above steps are performed as long as the list of 

mat. This is also saved in the virtual memory (FIG. 17, replacements is not empty. 

Block 190), until the VS file is created (FIG. 17, Block 196). 20 The "GetValidXXXX" (FIG. 17, Block 198) unit contains 

Given a string of topics and the name of the product those various routines under the prefix "Get Valid". These routines 
topics are related to, The "ProcessAllTopics" (FIG. 17, are responsible for getting a valid input from the user. 
Block 192) routine will create a list out of the topics and for Invalid input is a blank line, gibberish, etc. 
each topic the following shall be performed: Each of these routines calls "OutputComboQuery" (FIG. 

If the topic is new (e.g. — the VSD never mentioned it 25 17, Block 186) to ask the user to re-enter the answer to one 
before), the system asks the user for a text string which shall of the wizard's questions. These routines are designed to be 
be used as a question for the topic. If the topic was executed until the user gives a valid input, 
recognized by the system as an existing topic, this query is The task of the Detection Engine (DE) is to detect 
skipped. The system asks the user what answer should different situations and twist the session course in a way the 

received on the question so that the appropriate recommen- 30 VSD decides. Extreme situations can be an industrial spy in 
dation is the current product. the system, a user that wishes to purchase valuable products, 

The question for the topic and the expected value are or another thins, according to criteria defined by the VSD. 
saved by this routine in the virtual memory (FIG. 17, Block The detection engine can be thought of as a special, secret 
190), in the "on the fly" generated SL format. The pair department in the VS. This department never produces any 

topic-value is also saved separately under the handle "con- 35 external output, instead its results are written to the system 
dition". data in the virtual memory. Thus, the results of its rules 

Both of these routines use "OutputComboQuery" (FIG. modify the flow of the session. 
17, Block 186) to generate output and "GetValidXXXX" Some of the "extreme situations" are handled by default 
(FIG. 17, Block 198) unit to read a valid input. in the DE, while the user is free to add such situation 

After a specific product has been discussed, the "MakeR- 40 definitions at will, 
ule" (FIG. 17, Block 198) routine is invoked to collect The structure of the DE is the structure of a department 
conditions of the virtual memory (FIG. 17, Block 190) and without the messages. It is fully rule-derived as the results 
organize them all under the handle "rule". After this proce- of a rule are either the modifiable features (such as 
dure the conditions are delected so the different rules are not "maxZeroes", business strategy, etc.), or any other type of 

mixed up. 45 information the VSD wants to put in the DE. 

The "Write VSFile" (FIG. 17, Block 194) routine is The procedure is operated as follows. The SEU is always 
invoked by the main routine and is used to copy data aware of the DE physical location on the disk. While 
previously saved in a working memory to a file. It opens a working in a normal mode, after each question outputted to 
file with the name specified by the user plus the extension the user — the SEU referring to the DE and scans it using the 

"sell". All information stored under the handle "products", 50 routine "LoadDE" which operates exactly like "FireNex- 
"topics" and "rules" is flushed to the file. tRule" (FIG. 2, block 34) only with a different "Perform" 

"Write VSFile" (FIG. 17, Block 194) is called every 10 (FIG. 2, block 40) routine: "twist". The "Equate" (FIG. 2, 
minutes or so, in order to back up the existing work of the block 44) function, however, remains the same. 
VSD. The "Twist" routine takes the results of the detection rules 

The wizard library is used to generate an interesting, 55 and write then to the "system" section of the memory. It acts 
human output. differently based upon the given input. 

The file is divided to sections each of which is initiated by If the result is a keyword ("maxZeroes", "departments", 
a certain keyword and contains several strings delimited by "business_strategy", etc.) — "Twist" replaces all existing 
commas. information regarding the keyword. 

The strings themselves are represented as a normal text 60 If it some other input — "Twist" adds it to the memory and 
strings but they may contain "replace tags" of the format no overwriting takes place, 
"^'xxxxx'^" "xxxxxx" is some line of text. While Some of the built-in options are as follows: 
execution, this line shell be replaced with information gen- (*) Transfer to chat — given the appropriate conditions that 
e rated on the fly, by "OutputComboQuery" (FIG. 17, Block were accomplished (following criterias described by the 

186). 65 VSD), the DE is able to generate a message to the user that 

Tlie "OutputComboQuery" (FIG. 17, Block 186) routine someone wants to talk to him and transfer him to chat with 
is called with a query name (keyword) that must be specified a human sales representative. 
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Show the door — the DE may decide, based on the con- During the session, the user answers the questions, 

ditions supplied by the user, that the current user is a spy or receives the comments of the SEU and messages, is exposed 

another intruder and is able to gently encourage the user to to multimedia and is able to purchase any product in real 

exit, saying something like "sorry, but we have no products time, 

available for you" or "Pm really busy right now, could you s After the session is finished, the program creates a file 

come back later?" which holds everything saved previously by the SEU to the 

Lengthen the session — the DE is able to create a longer memory 

sessions by changing the "businessStrategy" information ^ filc ^ transported immc diately (FIG. 18, Block 214) 

and/or changing the max^roes constant to the server (FIG. 18, Block 214). The implementation of 

More/less am mauon--TT>e DE can abo change the visual ^ ' ' Web-based 

appearance of a question/answer by outputting more multi- -n. i j-« • i ^ • * -c »u ,u 

media or, on the contrary, prevent the SEU to output one or v ™- ™ e ^ ^a^VZ^ 2*°™ 

more types of multimedia. This is done by formatting the use £ ***** ^ an bu ^f g "™ L .P a ^ s » the SEU nor- 

HTML script generated by the SEU and removing all , does > , the P ortab . le SEU builds local windows and 

references to pictures, sounds, movies, etc. ' controls on cUent Slde ( GUI ) (see FIG. 3). 

Changing the test of a question/recommendation— based 15 A 150 * rather than loading the e-shop as a file from the 

on a specific conditions, the DE can replace the text of a server's computer (FIG. 18 Block 204), the portable SEU 

specified question/recommendation with another text sped- loads it by using an HTTP connection (FIG. 18, Block 208) 

fied by the user. through the Internet. 

The technique is the same as mention in the Visual The credit card number transferring process differs from 
Appearance. 20 the process described previously (see FIG. 15). While work- 
Such a replacement can also be done with multimedia. ing with the portable code, the whole credit card number is 
Add to VIP list — (available after the session only) — the received by the SEU, encoded and passed on to the server 
DE decides which customers are "interesting" from the (FIG. 18, Block 204) in one piece with a log and private 
VSD's point of view and adds their e-mail to a special log client information (FIG. 18, Block 214). The reason for this 
for future use by the VSD. 2S difference is that when the entire program resides on the 
The Portable Code SEU implementation structure and clieQt compu t e r, the possibility is reduced that the user's 
description is shown in FIGS. 18 and 19. The Portable Code credit cafd number WQuld be stokn 

S l u\ 3 e f mbodl f me ° t of th * P resent m T, U ° D There are two particularly important routines that require 

which has the advantage of reducing the amount of time . , tl _ iL , it _ , 

• a f a * . <r u *. v * a !u special attention: the routine that saves the virtual memory 

required for data transfer between the client and the server _ / C1 , ... , , c . ./ 

though the Internet. Currently the speed of Internet con- 30 to a , file ' and ^ one that ***** the lo * from the client Slde 

nections is not very high. Sending the whole SEU+the „ ^ ™ „ * Q ™ . 

e*hop to the client side needs only three transactions: one ^ "PutMemToFile (FIG. 18, Block 216) routine starts 

to transfer the SEU, the second to transfer the e-shop to the b y gathering all flags' handles such as "info", "previous" 

client and at the end of the session, the third to transfer the and al1 otncrs mentioned through this document. Then, it 

history of the session (log) back from the client to the server. 35 continues by creating a list from each piece of information 

For comparison, the SEU implemented in CGI (or any other associated with those handles. Each list is written to the file, 

non-portable web server technology such as ISAPI) requires As the file returns to the server, the file is decomposed and 

one Internet transaction per question\comment\answer or saved in the log file along with other similar files, 

message. A regular session may include 30-60 transactions The "SendLog" (FIG. 18, Block 218) function sends all 

such that a portable-code implementation of the SEU results 40 the collected information received through the session and 

in a significant acceleration of communication. In this the credit card information (if there is any) to the server 

implementation, the entire work that needs to be done by the (FIG. 18, Block 204). The function opens an HTTP connec- 

SEU is done at the client side while the server is only tion (FIG. 18, Block 208) to the server (FIG. 18, Block 240), 

responsible for uploading the SEU and the e-shop, and for sends a POST request with all the collected data and receives 

receiving the log file. 45 a confirmation about successml data transfer. The confirma- 

There are two approaches developed to embed the SEU in Uon fa sem ^ text/plain MIME type< 

portable code scripts, such as Java applets. Either the SEU lf confirmation is not reccivcd> thc SEU reports to ^ user 

is written in portable code language or the SEU is invoked ^ ^ 2Q6) ^ * be leted 

fan™ ^ m " * ecausc of abscncc of a (FIG. 18, Block 208) 

In the first approach-the SEU works almost the same as 50 ^ SQ ™ T ( FIG '. 18 >. Bkx * 204 >- 
if it was embedded using common web server technologies ^ confirmation is given by a server side application 
(CGI, ISAPI, NSAPI and the like). The difference is that the writteQ in CGI > ISAPI or other web *™ technology which 
system works in consult mode at the client side (FIG. 18, received the data, saves it to the local disk in a previously 
Block 212). The steps of loading and launching it are as specified location and, if the above two tasks were corn- 
follows. 55 pie ted successfully, sends confirmation to the client (FIG. 

Once the request has been made to the server, the portable 18, Block 206). 

code written SEU script downloads itself to the client In the second approach, the SEU is interpreted by a 

computer being operated by the user (FIG. 18, Block 210). transportable code implemented interpreter. 

The SEU stays in the virtual memory of the client The program, consisting of the SEU, the e-shop and the 

computer throughout the session (FIG. 18, Block 212). 60 interpreter, is a stand-along application (FIG. 19, Block 220) 

Once at the client side, the SEU uses the open connection which starts execution once all of the components are 

(FIG. 18, Block 208) as an input stream and loads a copy of downloaded to the client computer (FIG. 19, Block 206). For 

the e-shop to the clients 's memory (FIG. 18, Block 210). this embodiment, the SEU must be implemented by an 

The session takes place on the user's computer (FIG. 18, interpretable language (such as BASIC). 

Block 212). All of the features are available by using the 65 Once the interpreter is downloaded by the client, it builds 

GUI (See FIG. 3), as described for the Web browser inter- an HTTP request, loads the SEU and starts the SEU. The 

face. remaining processes are operated as describe before. 
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The term "interpreter*' refers to an interpreter from the For example, for the SEU based implementation example 

source language of the SEU to the destination language (the and structure, all the data processing and calculations are 

portable code). made by the SEU. When the user contacts the Shopping 

Because the e-shop may contain links to a database (FIG. Smart icon with the mouse or other pointing device, pref- 

19, Block 222), which are impossible to transfer using any 5 erably substantially without "clicking 5 on the icon, the 

known portable code, the database must be converted to a 'onMouseOver* event launches the "ShopSmart" function 

file which is transferable (FIG. 19, Block 228). written in the page in a form of script. The "ShopSmart" 

The "DBtoNoDB" (FIG. 19, Block 226) routine uses function launches the SEU in a special mode for Shopping 

simple string search to scan through the rule base and find Smart, in order to run Financial Purchase Manger mecha- 

references to a database (given by file name and entry 1Q nism. The SEU sends the response to Shopping Smart 

number). It creates new, temporary, e-shop file in which window in a form that was described above. Pressing the 

every database reference is removed. Instead, an answer is "Recalculate" button will send the updated information to 

written in SL format. This answer will consist of the the SEU. The SEU sends the results back to the Shopping 

product's name, the recommendation string and the price of s mart window as is usually done in regular CGI or other 

the product. \y* eD Server Technology processes. 

The "DBtoSL" (FIG. 19, Block 228) routine is used to 15 ^ window b closed when it ^ mouse or othef poi[Uer 

convert any database written in SQL, Oracle or DB2 format device fa « off> . the { such ^ , he GUI indicator (a mtsot 

to a transferable file (FIG. 19, Block 228) The routrne Qrarrow for le) ^ i ongervisiWe incontact with the 

generates a list of every row m the original database. The k ^ h ^ ^^q^ eveat which is M from 

database fields are written to a text file separated by com- ... tU c ( (U <cu • e ^> 

mas. There is a ".» (period punctuation) at the end of each 20 Wltlun the reference 10 the Sho PP in S Smart ™ ar V lcon 

row ima S e ' 

The SEU automatically identifies the first word as con- . ™ c * xo ? f " ^Jf* 0 * ^ <<Shop P ing Smaft " funC " 

taining the object's name and the second word as containing ^ on 15 » foll °^ ™* Sh °P Smart Procedure opens a win- 

the objects's text. For any other words it assumes they are Wlth an "™ L ^ marku P, lan ^ a S e ) fo ™ ° r 

the style, the asking format, "negotiable" flag (on or off) and 25 ? lhcr f,^^r structure). The ShopSmart procure calls the 

"multiple" flag respectively. The process is sLilar to the one . °P en ^ff n m ° rder to «pen the window. The URL that 

previously described for enabling the SEU to interact with 15 passed t0 °P cn 45 a P aramctcr 1S: 

the database direcUy. This routine may be used to transfer [SEU]?vs-[the vs name]&MODE-FPM 
comments, questions and answers which are not do contain 

product information. 30 Usin S the modc "FPM", the SEU will know that the 

Note: The detection engine has the ability to determine "Perform" (FIG. 2, block 40) routine which deals with FPM 

whether or not to recommend to the user to start the session 15 required. Thus, the normal SEU process is halted and the 

by using portable code. The DE may give a recommendation appropriate "Perform" (block 40) routine (for FPM) is 

to start downloading the portable code version of the appli- invoked. 

cation to the user, based on the time of day and the speed of 35 Alternatively and preferably, the Shopping Smart function 

the connection, which is verifiable by the use of standard can be implemented by using substantially only JavaScript 

functions such as "ping" ( or otner similar languages as advanced markup language 

The Shopping Smart * summary software module is a for ^ l VP es of ^P 18 ' such * Java language and the like, 

preferred feature of the present invention which allows the WheD thc ™ cx contacts The Shopping Smart icon with the 

user to view the list of products which were purchased. This *o mouse > the 'onMouseOver' event will launch the "SbopS- 

feature is implemented within the Communication Environ- mart " faction. However, in this implementation, the tunc- 

ment using Web server technologies (CGI, ISAPI and so on). tion works differently. The function is operated as follows. 

The user can see the contents of the purchase at any point of ™* ShopSmart procedure takes information about pur- 

the purchase process. chased products and displays that information in a table, 

Preferably, every HTML page used as a GUI for the 45 positioned in a previously opened window. The data about 

present invention includes an icon to represent the Shopping Purchased products and prices is generated by the SEU 

Smart feature. When user moves the mouse over the icon, a throughout the session and is accumulated m the dynami- 

window is opened. In the window the user can see a list of call y created KmL P a S es as a hidden ^ of in P ut For 

products, previously marked as purchased, with their respec- example : 

tive prices and quantities. Below the list, the user can see the 50 <INPUT TYPE="hidden" NAME="sys_purchased_01" 

total sum of the cost of the purchase. The button "Recalcu- VALUE="Brand X mouse"> 

late" is supplied below for the user to push. The user has the <INPUT TYPE="hidden" NAME="BRAND X mouse" 

ability to change the quantity of any purchased product in VALUE**" 30"> 

the appropriate "Quantity" text field and recalculate the total <INPUT TYPE-"hidden" NAME-" Currency" VALUE- 

sum according to the new quantity. Moving the mouse 55 "$"> 

cursor out of the Shopping Smart window causes the win- The shown data represents the product i Brand X mouse* 

dow to be closed automatically. that costs 30$. By scanning names and finding "sys_ 

The Shopping Smart function is preferably always avail- purchased_nn" (where 'nn' is any integer) "ShopSmart" 
able on any Web page being used as part of the GUI by the knows the name of the purchased product. Then, the match- 
present invention, so that there is no need to go to another 60 ing price string can be retrieved according to the name and 
Web page in order to view this information as described then concatenated with the currency string taken from the 
previously for other prior art on-line shopping implementa- "Currency" hidden input. "ShopSmart" outputs the product 
tions. name and price as row of HTML table to window. The same 

The Shopping Smart function can optionally and prefer- action is performed for all found products. The total sum is 

ably be implemented in various languages by using various 65 calculated and displayed under the products list. As a result, 

technologies. The implementations below are possible the user can see the full list of products, their prices and the 

options for full and partial solutions. total sum of the purchase. 
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According to another preferred embodiment of the present 
invention, "multiple Sales Representatives" can be imple- 
mented with the SEU. Such an embodiment can be used 
within a framework of a plurality of different Virtual Shops 
(VS) being operated with the same Sales Engine Unit (SEU). 
The VSD can build a number of VS's (separate VS for each 
department, product line or just a different electronic sales 
representative character) and to pass the VS file name on to 
SEU as a parameter. At least one characteristic of the 
different sales representative "characters" can determine the 
interaction with the user. 

The manner in which the VS is loaded is optionally and 
preferably different for each Communication Environment 
(CE). As an example for CGI and HTML, in CGI mode the 
SEU is launched by an HTML FORM. In order to launch the 
SEU with another VS name, other than the default name, the 
FORM tag should look like: 

<FORM METHOD-POST ACnON-<SEU 

name>?VS-<VS name>. . . > 

where <SEU name> is the real name of the SEU file, and 
<VS name> is the real name of the VS file. 

The SEU gets <VS name> from the "QUERY_STRING" 
environment variable, previously written by the server, and 
loads the names VS file instead of the default. 

The described method enables a separate VS to be imple- 
mented for every shop's department. Such an embodiment 
allows much of the work required for building the first VS 
to be reused for further VS implementations. In order to 
incorporate new departments in an existing VS, references to 
the different departments must be included aod the infor- 
mation concerning each department saved in another file. 
The references are represented by strings. Each string 
includes the reserved word "ref", in order to recognize the 
reference as a reference, and a path to the referenced 
department. As an example, the reference can look like this: 

PrintersRef-ref("/cgi/printers.seU"). 
The SEU will recognize the references and load all refer- 
enced files. In such a way, the SEU will have the full data 
of the whole shop. 

If the different e-shops are constructed with different sales 
representatives, the DE preferably determines which e-shop 
to launch. For example, if one virtual sales representative is 
a woman named Kelly, another is a former boxer named 
"Rocky" who speaks accordingly, and yet another is a 
teenager named Jessy, the DE may decide which virtual 
sales representative is the most suitable for the user, based 
on user gender and age, the time of day, the speed of the 
connection, and so on. 

The reasons for constructing different types of virtual 
sales representatives include the ability to use different 
languages, language styles, multimedia representations, or 
to give the user a variety of "people" to choose from. 
Another reason is that the use of multi-file VS is extremely 
useful when linked to an existing site. Yet another reason is 
to enable the user to receive a recommendation from each 
display on the GUI separately, instead of forcing the user to 
go through the session from the beginning. 

In addition, working in multi-files also confers a great 
deal of flexibility for the DE. The DE may construct the 
session by deciding on the departments which are "off-limit" 
to the current user. For example, if the user is a spy, the 
department which gives information about the new line of 
the company's products could be made "off limits" to such 
a user. 
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According to yet another preferred embodiment of the 
present invention, there is provided the ability to transfer to 
"chat" mode from the SEU. 

Transfer to chat, shown in FIG. 20, is the operation of 
s detecting and transferring to live chat. The motivation here 
is the detection of users with whom such "chat" would be 
beneficial. 

The DE is responsible for the detection of clients that the 
VSD has specified as "interesting" (FIG. 20, Block 230). For 

10 example, the VSD may construct a rule that says that only 
clients who bought 5 products or above, enter the chat. The 
rules according to which the DE will transfer the user to a 
live chat reside in the DE department. After the DE has come 
to a conclusion that the specific user should be transferred to 

15 chat, it must check for an available live human sales 
representative. Such a human sales representative is consid- 
ered to be unavailable if all of that representative's previ- 
ously opened browsers are connected to users. 

If no human sales representative is available, the DE 

20 allows the SEU to continue the session without generating 
any message to the user. The DE then places the user on a 
queue and attempts to lengthen the session as much as 
possible while waiting for such a human representative to 
become available. After each "Post" request from that user, 

25 the DE automatically checks for an available line to such a 
human sales representative. 

If a free line can be found, the DE constructs a page with 
a message to the user that human sales representative X 
would like to speak. After sending the page to the user, the 

30 DE immediately constructs a memo for the human sales 
representative which is a brief overview of the session with 
the user, including all the information the user has supplied. 

After performing each of the following tasks, the DE 
connects the user to the chatter and the SEU's session with 

35 the current user ceases to execute. 

If no free line could be found and there are no more 
features available to lengthen the session, the DE sends the 
user a message saying something like "Joe would want to 
talk to you so much, but all lines are busy. Can you come 

40 back later so he could talk to you?". The message sent in this 
situation is preferably constructed by the VSD in the process 
of building the shop. 

The chat function is operated as follows, with reference to 
FIG. 20. The "ConductChat" (FIG. 20, Block 232) routine is 

45 the core for the 'transfer to chat 7 mechanism. 

It starts by launching "CheckFreeLine" (FIG. 20, Block 
234) to find an available line to transfer the user for the chat. 

If "CheckFreeLine" (FIG. 20, Block 234) returns "NO_ 
LINE", "ConductChat" (FIG. 20, Block 232) will indicate 

50 this situation by turning a flag "ChatQueue" 'on'. The user 
is now in a queue for a chat (FIG. 20, Block 236). Whenever 
the SEU sees that flag, it will invoke "CheckFreeLine" (FIG. 
20, Block 234) again, trying to get the user to chat with the 
human sales representative. 

55 If "CheckFreeLine" (FIG. 20, Block 234) returned a 
human sales representative's name, "ConductChat" (FIG. 
20, Block 232) launches "BuildUserMsg" (FIG. 20, Block 
238) with the parameter "in", followed by "BuildMemo" 
(FIG. 20 Block 240) to prepare both the user and the human 

60 sales representative for the coming chat. "BuildMemo" 
(FIG. 20, Block 240) clears the virtual memory of any trace 
of the user, finishing the session (FIG. 20, Block 242). 

The CheckFreeLine (FIG. 20, Block 234) function checks 
for an available human sales representative for a chat. No 

65 parameters are passed to it; instead it works with an external 
INI file. The INI file contains the following information, 
written in the usual INI format: 
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[lineslnfo] 
Kelly=0 

Kelly_IP=192.156.9.786 
John»l 

John_IP=222.999.1.333 
Roy-1 

Roy_IP=201. 967.7.123 

"Roy", "John" and "Kelly" are the names of the human 
sales representatives, while the numbers to their right are the 
flag (0— human sales representative's current browser is 
free, 1 — human sales representative's current browser is 
busy). For each name, the IP address is also specified to get 
the full identification of the human sales representative when 
the users are matched to the human sales representatives 
throughout the chat. 

"CheckFreeLine" (FIG. 20, Block 234) finds the section 
"lineslnfo" and packs all the strings that follow it to a list. 

The procedure then starts processing the list, by breaking 
each of the list elements to a "Name=IsBusy" structure and 
checking if the sales representative is free. If a free sales 
representative is found, "CheckFreeline" (FIG. 20, Block 
234) returns the corresponding "Name"; if not, the proce- 
dure returns "NO_LINE". 

The "BuildUserMsg" (FIG. 20, Block 238) routine 
expects one of the following parameters: "in" and "out". 

When it is launched with the parameter "in", this routine 
generates an HTML page for the following purposes: to 
inform the user of the transfer to a chat mode; and to 
initialize the chatter with some information that is passed to 
it by a hidden parameter residing in the page. It should be 
mentioned that the chatter is a different program, isolated 
from the SEU. 

The form that is built is as follows. 

<Form method-Post Action-/cgi-shl/chatter 
exe?MODE«CLIENT&STATE=INIT> 

<Input type=hidden Name="clientName" 
Value- *client's name as was supplied in the beginning 
of the session* > 

The next portion is where the message for the user is 
written: 

<Input type=hidden Name =" Sales representative" Value= 

*The sales representative's name*> 
<Input type«hidden Nameo"Sales representative^' 

Valuer *The sales representative's IP address* > 
<Input type-hidden Name-"Sales representativelP" 

Value=*The sales representative's IP address. *> 
<Input type=hidden Name="Data file" Value=*data file 

name*> 

<\Form> 

The parameters "data file", "Sales representative", "Sales 
representativelP' and "ClientName" are those which shall 
be used by the chatter for initialization. 

When the procedure is launched with the parameter "out", 
it generates a plain text message to inform the user that sales 
representative X would like to speak with the user, but that 
the representative is busy. The message could also suggest 
that the user could come back later, when X would not be as 
busy. 

The "BuildMemo" (FIG. 20, Block 240) routine con- 
structs a file to be passed to the chatter which displays the 
information in the sales representative's window. 

Given the appropriate user's handle as a reference to the 
virtual memory zone that stores all the information about the 
user since the session started, "BuildMemo" (FIG. 20, Block 
240) can work in one of the following ways. 
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If the VSD specified in the "config" section of the VS an 
"important" set of the form "important(interest, age, money, 
. . . )", which describes the major issues that the sales 
representative needs to know when entering a chat with the 

S user, "BuildMemo" (FIG. 20, Block 240) processes the 
topics by their names, given on the right side of the "=" sign. 
It does so by referring to the appropriate handles in the 
memory, specified by those names, and retrieving the infor- 
mation that resides under those handles. 

10 If no such section is specified in the INI file, or if it 
contains no data, "BuildMemo" (FIG. 20, Block 240) looks 
at all handles, but retrieves only the information meets the 
following conditions: first, that the information is of the 
form "(X, Y)" and second, that neither X nor Y are keywords 

15 (except the "purchased" keyword which identifies the prod- 
ucts purchased throughout the session). 

After the information was read from the memory "Build- 
Memo" (FIG. 20, Block 240), the information is placed into 
a file with the same handle which was previously generated 

20 by the SEU for referring the appropriate memory zone. 
In each of these approaches, "BuildMemo" (FIG. 20, 
Block 240) goes through the entire memory zone. Regard- 
less of the action taken with a handle, that handle is delected 
from the memory. In the end, all handles associated with the 

25 current user are removed so that this user no longer exists 
from the SEU's point of view. 

As shown in FIG. 21, the chatter software module is a 
separate program designed for communication between the 
user and the sales representative. It has two modes: user 

30 mode and sales representative mode page (FIG. 21, Block 
246). For "user" mode, it is launched by the DE (FIG. 20, 
Block 230). The sales representative runs his or her own 
chatter software module locally, declaring by doing so that 
he or she is ready to have a chat. The sales representative 

35 sees a few browsers, one for each of the users, while the user 
sees only the progress of the user's own chat with the sales 
representative. 

Every time the sales representative opens a browser, it is 
considered by the chatter to be connected to a different sales 

40 representative. Thus, every time the word "sales represen- 
tative" is used throughout the document, it is usually 
describing a single "user-sales representative" connection. 

As described previously, the chatter can work in two 
modes: user and sales representative page (FIG. 21, Block 

45 246). The mode in which the chatter works is passed to it by 
a parameter. The mode is 'user' by default. 

When the chatter is activated, it checks to see if it is 
launched for refreshing the chatter page (FIG. 21, Block 
244). The chatter page is refreshed automatically every 15 

50 seconds. The "state" parameter contains the state of the 
channel, identified by the "channel" parameter. The 
examples for invoking the chatter are shown below. If the 
current state is "refresh" (FIG. 21, Block 244), the chatter 
calls the "RefreshChat" (FIG. 20, Block 262) function in 

55 order to send an updated chat page. In both 'user* and 'sales 
representative' mode (FIG. 21, branches of block 246), the 
chatter tests if the channel between the user and the sales 
representative exists (FIG. 21, Block 248). If the 'STATE' is 
'INIT the channel does not exist (FIG. 21, Block 248, the 

60 branch marked with "no") and thus the chatter calls the 
"BuildNewChannel" function (FIG. 21, Block 266) in user 
mode and "RegisterSales representative" (FIG. 21, Block 
250) in sales representative mode and exits. 

If the channel exists (FIG. 21, Block 248, the branch 

65 marked with "yes") and the "Send" button was pressed by 
either the user or the sales representative, the message 
received from the user or the sales representative is stored in 
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the channel's storage room (FIG. 21, Blocks 254, 260). If the The description of "BuildMemo" (FIG. 20, Block 240) in 

"Leave the Chat" button was pressed (FIG. 21, Blocks 252, the Transfer to chat' section of the present Application 

256 — the branches marked with "yes"), the message "User describes the generation and transfer process of the user data 

has left the chat", or "Sales representative has left the chat" and the sales representative's name from the DE to the 

is stored (FIG. 21, Blocks 258). The message that is written 5 chatter (FIG. 20, Block 230). 

depends on the current chatter's mode. The user IP address is received from the HTTP server 

"UpdateRegister" routine (FIG. 21, Block 264) is called, using standard CGI (or other Web Server technology). The 

in order to update the sales representative state. The "Upda- data is of the form as shown above. After those operations 

teRegister" function (Block 264) marks the sales represen- the function "BuildUserResponse" is called, 

tative as "available" when the user left the chat, or deletes 10 The function puts a new sales representative's name and 

the sales representative from the section [lineslnfo] when the IP address into the section "lineslnfo" of the INI file. If the 

sales representative left the chat. pair 'name-IP address* already exists (in the case the sales 

The channel storage room looks like a section in a INI file representative wants to conduct two or more chats 

where the name of the section is the name of the channel simultaneously) the IP address is slightly changed (by 

(channelO, channell, channe!2 . . . ). The channel's storage 15 appending letters 'a', 'b' and so on to the end of the IP 

room contains data in the format shown below: address). This action is done in order to give every active 

[channel 0] browser, or connection, full identification, 

sales representative_name-Michael After that, the chatter treats each entry in the "lineslnfo" 

sales representative_IP-132.63.98.65 section as another sales representative. The sales represen- 

user name«John 20 tat * ves name * s taken ^ rom lne mitial P a g e of registration. 

-i^-i f-c qq c Th c initial f° rm includes a text field for entering the name 

user_lF=123.65.8y.5 of ^ sa]eg representative . initial form wiu launch the 

sm_msg=Hello, glad to see you in our shop . . . chattcr as shown below: 

user_msg=Hi, I would like . . . <FORM METHOD-POST 

sra_msgo. . . 25 ACTION="/cgi-shl/chatter.exe?MODE«SALES 

user_msg*. . . REPRESENTATIVE&STATE-INIT"> 

[channel 1] T& e sales representative's IP address is received from the 

sales representative jame-Daniel HTrP ^ in th * same wa y as the user ' s IP address - 

sales representative IP-120 253 45 5 H ° W the ^ lt& re P reseDlative ' s data a PP ears in tnis form is 

v — 30 described in the "Transfer to chat" part of this document. 

user_name=Alex ^ Detection Engine ( F1G 2 0, Block 230) uses the infor- 

user_IP=157. 125.84.235 mation later on, to decide which sales representative is 

sm_msg=Hello, glad to see you in our shop . . . available or less occupied so it can distribute the users 

user__msg=Hi, I am looking for . . . equally between the sales representatives. 

The functions for these channels work as follows, with 35 After registering the sales representative, the chatter sends 

reference to FIG. 21. There are two situations in which the a page with a "Line is free" message to the sales represen- 

chat page is refreshed: for an existing chat (the 'channel* tative. The page is refreshed every 10 seconds in order to 

parameter specifies a live channel); for initialization of the check whether the browser has started a chat (the connection 

chat for the sales representative (the 'channel' parameter is alive). Refreshing is done by using a standard markup 

specifies a free line, such that the connection is idle). 40 language tags within the markup page header. 

In the case of an existing chat, the function scans the The function "BuildUserResponse" builds a frame of 

current channel's storage room for chat elements (string in markup language pages (as HTML, DHTML and like), 

form "sm_msg=. . . " and user_msg«. . .") and extracts the The pages include a header page with the sales represen- 

parts of chat text from them. Then, a markup language page ta five's name, a Chat History page with reflects everything 

is built from the gathered text and sent to the HTTP server. 45 that was said by both the user and the sales representative 

In the case of initialization of the chat for the sales since the chat was initiated, and a Message page which is the 

representative, the entire channel's data is scanned in order active text area for writing. 

to test if the current sales representative is involved to chat The Chat History page is automatically refreshed every 15 

by the Detection Engine (FIG. 20, Block 230). For this seconds. The refresh is implemented by using standard mark 

purpose the sales representative's name and the connection's 50 up language tags within the Chat History page header. 

IP address are matched to the current connections's data in The Message Page includes two buttons: "Send" and 

every section. If no matching data can be found, a page with "Leave Chat" for proceeding or interrupting chat respec- 

the text "Line is free" is sent to the free connection's lively. Both of them are * submit' buttons of the form, which 

browser as described in the "RegisterSales representative" means that pressing either one of them launches the chatter 

function (FIG. 21, Block 250). If a new channel for the 55 program. The event of proceeding or interrupting the chat is 

current sales representative is found, the function "Build- handled by the chatter program itself, which recognizes the 

Sales represenlativeResponse" is launched. button that was pressed based on the button's "VALUE". 

The function "BuildNewChannel" (FIG. 21, Block 266) The function "BuildSales representativeResponse" builds 

takes the data previously prepared by the Detection Engine a frame of markup language pages (as HTML, DHTML and 

(FIG. 20, Block 230) about the user and the sales represen- 60 the like). 

tative's data and builds a new channel for them. It builds the The pages include a Header Page with the user's name, a 

channel name by concatenating the word "channel" with the Chat History page (the same as above), a Message page (the 

channel's number. The channel's number is increased by 1 same as above) and a Purchase History page, 

for every new channel, starting with 0. A new channel's The Purchase History page contains the list of options and 

storage room (a new section in the INI file) is created and the 65 products chosen by the user in this session with the SEU, 

corresponding data about the user and the sales representa- before the chatter was entered. This list aids the sales 

tive (names and IP addresses) is written into it. representative to move the chat in the right direction. The 


12/06/2003, EAST Version: 1.4.1 


6,070,149 

41 42 

page is built from the data of a file that was previously leading designer"); d) something related to a feature 

prepared by the Detection Engine (FIG. 20, Block 230). The ("diamond bigger than one carat"); e) a minimum feature 

name of the file is obtained by the chatter from the initial ("lowest price'*, "slowest compute^'); f) a maximum feature 

form (the form which launches the chatter). ("fastest computer", "biggest diamond"); g) a negative fea- 

The advanced parser link to the SEU is shown in FIG. 22. 5 ture ("computer that is not big", "diamond that does not cost 

The parser is responsible for a) translating the user's queries 1000 dollars", "operating system which is not Brand X"); h) 

(written in natural language) to conditions, b) skimming the query 1 and query2 ("a very fast computer or big computer", 

rules in the VS file to find rules that contain those conditions, "computer with 8 MB of RAM or with 3.2 MB of disk 

c) handling cases such as inappropriate words by activating space"); i) queryl and query2 ("computer with 8 MB of 

several side mechanisms. In the last situation, those mecha- 10 RAM and 3.2 GB of disk space", "dress which costs 2000 

nisms preferably answer the user in a form of "Don't be dollars and is from the leading designer"), 

rude", for example. The procedure for operating the parser is as follows. The 

The parser's answers are recommendations of a product "GetQuery" routine (FIG. 22, block 310) is the main parser 

or type of a product, or stereotyped answers as written in the routine. It is invoked once the SEU discovers that the user 

VS file as the results of the corresponding rule. 15 entered a query. 

The whole mechanism works with two different files. The First, the "DumpRedundant" routine is started to remove 

first file, a general file, holds the language fragments such as all punctuation marks and the words that are marked as 

prepositions, adjectives, nouns, etc. The second file, the "words to be ignored". "DumpRedundant" returns a list of 

product keyword file, holds the professional terms that are words on which the parser itself is invoked, in the form of 

relevant to the VSD's industry. For example, if the industry 20 the "Comprehend" routine (FIG. 22, block 268). The 

is diamonds then the file may contain words like "carat", "Known" routine (FIG. 22, block 312) is then launched. It 

"cut", "clarity". travels down the list of words and checks every word to see 

The general file is preferably supplied with the software if it's a known word. The routine looks for the word both in 

and is more preferably renewed occasionally. The other the language file and the professional terms file. In case 

product keyword file is preferably and optionally con- 25 unknown words are found, "Known" (FIG. 22, block 312) 

structed by the VSD, as a part of building the e-shop, gathers them all in a list. After that, "Known" (FIG. 22, 

although industry-specific libraries could also be used. block 312) reports to the user that a portion of the question 

The language is defined with a number of relations was not understood. The user is given two options, to 

between the product keywords, the most important being the formulate the question differently, or to give up the question, 

schema. A schema is a description of the logical structure of 30 This output is done through "HandleErr". 

the VS. In the parser, the schema is the "entity network" for "HandleErr" — In any other type of query other than those 

the language. A schema entry follows the form: ENTITY described or in the case the "Known" routine (FIG. 22, block 

ASSOCIATION ENTITY; this signifies that the two entities 312) encounters an unrecognized word, the parser outputs an 

are bound together by the given association, such as 'dia- "error". If there is an unrecognized word, the word will be 

mond' from 'country', 'cut' of 'diamond', 'price' in 'she- 35 output also. Two buttons are output, labelled as "Rephrase 

quels'. the question" and "Give up". By pressing the "Rephrase the 

Both of the files contain the following items. First, there question" button, the normal SEU's session is suspended, 

is the schema of questions, which is the schema for all the same page is output again, regardless of whether the user 

possible questions to be asked such as color of diamond, answered the SEU's question. If the "Give up" button was 

clarity of diamond, country of export, etc. Next, there are 40 pressed, the routine checks if the user answered the SEU's 

names of objects, in which all known objects are listed, such question. If so, the session continues normally. If not, the 

as diamond, country, year. Third, synooyms for entities are question is output again, this time with no text area below, 

allowed, such as "stone" as the synonym for "diamond", The results of the parsing are stored in the virtual memory, 

"articulation" as a synonym for "cut" and so on. Fourth, and then the routine "Handle Res" is invoked. "HandleRes" 

synonyms for associations are allowed and can consist of 45 is the routine that works with the virtual memory directly, 

more than one word. For instance the association "on" is a and is responsible for deciding what action to take, 
synonym for "above", and the associations "in", "inside of As noted before, the "Comprehend" routine (FIG. 22, 

"within" are all synonyms. Fifth, some words and phrases block 268) launches the parser. The parser works in a 

are simply ignored by the system since they are not directly method called "parsing by difference lists." It means that all 

relevant to the meaning of questions. Ignored words are 50 of the functions that participate in the process of parsing the 

"give me", "tell me", etc. query have the input list as a parameter and return the 

Sixth, the units of measure for different entities are, for remainder of the list after a part of a query is parsed. This 

instance, "carats" when the entity is the size of the diamond, remainder is stored in the virtual memory. 

"MHZ", when the entity is "speed of computer". Seventh, The first action of "Comprehend" (FIG. 22, block 268) is 

there are synonyms for relational operators, for example to 55 to invoke the "Sentence" routine (FIG. 22, block 270). As 

state that a diamond is "bigger than" 1 carat. These syn- the "Known" procedure (FIG. 22, block 312) looked at the 

onyms are listed here. Eighth, alternative ways to designate list of words and checked the validity of each word, so does 

adjectives for "minimum" in the current application are "Sentence" (block 270) check for phrases. It has several 

listed, such as slowest, smallest, ugliest, less interactive. structures it recognizes. If for any reason the structure 

Ninth, alternative ways to determine equivalent adjectives 60 cannot be recognized, it gives the user the same options as 

for "maximum" are listed here, such as fastest, biggest, most the "Known" (FIG. 22, block 312) routine, 

beautiful, smartest. The first block of "Sentence" (FIG. 22, block 284) deals 

The parser recognizes at least nine types of queries: a) with the queries of the form "How fast is the computer 

something that is equal to a second something ("diamond "imaginary brand AAAA"?". 

with the red color"); b) something that is associated with a 65 It attempts to break the query to the form "Size -Entity- 
specific characteristic ("computer with 8 MB of RAM"); c) Constant". The structure of the sentence is considered valid 
something associated with another query ("dress from the if and only if the following rules are true. First, the "Entity" 
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is defined as an entity in the professional terms file. Second, cheapest dress". The query is decomposed to a form of 

the "Size" is a relevant "size" for the entity (for example, the "Min-Query". The structure is considered to be valid if and 

size "fast" is relevant for the entity "car" or "computer" but only if the "minimum" word is relevant to the entity (the 

is irrelevant to the entity "dress" or "diamond"). Third, the "minimum" word "slowest" is relevant to the entities 'com- 

"Constant" "is" or "belongs to " the "Entity" (for example, s P^ter' and 'rocket' but is not relevant to the entity 

the constant "digital work station" belongs to the entity 'diamond', for example), the entity in the "Query" query is 

"workstation" or "computer" but does not belong to the defined as an entity in the professional terms file, and the 

entity "diamond"). Fourth, the statement "Size-Association- "^^l**^? qu ^ „ „ L , , _ 

Entity" is defined as a valid schema, in which 'Association' . ™ e fifth . bloc * ° f Sentence FIG. 22, block 292) 

is the preposition used. For example, the phrases 'computer 10 handles quenes of Uie type the fastest computer' or the 

. , . / * c u . . c r-r^r->» biggest diamond . The query is decomposed to a form of 

is big or software from imaginary firm GGG are proper, «^x-Query". The structure is considered to be valid if and 

but not computer from big or software is imaginary firm Qnly if the « maximum » word ^ relevant t0 the entity (the 

GGG'". "maximum" word "fastest" is relevant to the entities 'com- 

First, the size is identified, because the size can consist of putcr * and < rockct > bui it is not relevant to the entity 

only one word. The identification is performed by examining 15 'diamond', for example), the entity in the "Query" query is 

all of the "rel_size" entries in the professional terms file. defined as an entity in the professional terms file and the 

Then, the routine looks for a "Constant", which can be only "Query" is a valid query. 

a professional term or product keyword such as "imaginary The sixth block of "Sentence" (FIG. 22, block 294) 

brand AAAA", "imaginary designer's cloth", "imaginary handles queries of the type "give me computers" or "tell me 

firm CCCC" so that the search is relatively small. The search 20 about the diamonds you have". The appropriate structure is 

is performed by concatenating the list of words to a string, "Entity" and thus, to be considered valid, the structure 

taking each constant defined in the professional term or simply needs is to verify that "Entity" is a valid entity (the 

product keyword file and checking for it within the string. entity is defined in the "professional terms" file). 

If a constant is identified correctly, the "ExpressEnt" The seventh block of "Sentence" (FIG. 22, block 296) 

(FIG. 22, block 274) procedure is invoked to determine if the 25 handles queries of the type ". . . faster than 200 MHZ", 

remainder of the list is a valid entity. If it is, the size is "bigger than 1 carat". The appropriate structure is "Rel-Val- 

examined for relevance to the entity. A relevant size is found Unit". The structure is considered valid if and only if the 

with a "rel_size" entry which consists exacdy of the entity relational operator is relevant to the unit (for instance the 

and size detected. If the size is relevant, the association is relation "fast" is relevant to "MHZ" and the relation "long" 

retrieved using "ExpressAssoc" (FIG. 22, block 280). If a 30 is relevant to "meters", but both of those relations are 

valid association is returned, the relevance of the constant to irrelevant to "litters"), and the value "Val" exists, 

the entity is determined by finding a "data" entry in the The eighth block of "Sentence" (FIG. 22, block 298) 

professional terms file which specifically states that the handles queries of the type "computer faster than 200", 

constant "Constant" belongs to the entity found. The validity "diamond bigger than 2". The structure should be "Rel-Val". 

of the schema is checked by a single reference to the 35 The structure is considered valid if and only if the value is 

professional terms or product keyword file to verify whether a valid numeric value and the relation is relevant to the entity 

the size found, the entity retrieved and the association used. There is a single measuring unit for the current entity, 

established exist together as a schema. so there is no ambiguity in such a reference. For example, 

The second block of "Sentence" (FIG. 22, block 286) the only measuring unit for "size" of diamonds is "carat" so 

handles the queries of the form "How fast is "imaginary 40 by saying "diamond with the size of 1", the phrase cannot be 

brand AAAA"?". It attempts to decompose the query to the misunderstood. However, if "size" is defined as "can be 

form of "Size-Constant". The structure of the sentence is measured as 'grams' or 'carats', the same phrase causes 

considered valid if and only if the "Constant" is defined in ambiguity. "IsSingleUnit" (FIG. 22, block 280) determines 

the professional terms or product keywords file as a constant only one such unit is possible. 

for any entity (for example, the constants "imaginary brand 45 The ninth block of "Sentence" (FIG. 22, block 300) 

AAAA", "imaginary brand BBBB" and "imaginary brand handles queries of the type "with a speed of 200 MHZ", 

CCCC" may be defined as constants belonging to the entity "with a size of 1 carat". The structure is "Ent-Val-Uoit". This 

'computer'. In addition, the "Size" must be relevant for the structure is valid, if and only if the entity is valid, the value 

entity corresponding to the constant and the statement is a valid numeric value, and the unit is relevant to the entity. 

"Size-Associalion-Entity" must be defined as a valid so The tenth block of "Sentence" (FIG. 22, block 302) 

schema, in which 'Association' is the preposition. handles queries of the type ". . . with a speed of 200", "... 

The third block of "Sentence" (FIG. 22, block 288) with the size of 1". The structure is "Ent-Val". In order to be 

handles queries of the type "how fast is the fastest computer" considered valid, the structure must fulfill the following 

or "how expensive is the dress of the leading designer". The conditions. First, the entity is valid and the value is a 

query is decomposed to the form of "Size-Query". The 55 numeric value. Next, there exists only a single measuring 

structure is considered valid, if and only if the "Size" is unit for the current entity, so there is no ambiguity in such 

relevant "size" for the entity, the statement "Size- a reference, as determined by "IsSingleUnit" (FIG. 22, block 

Association-Entity" is defined as a valid schema, and the 280). 

query "Query" is a valid query. The eleventh block of "Sentence" (FIG. 22, block 304) 

The size is located first and then the association within the 60 handles queries of the type ". . . the computer "imaginary 

question. The remainder is considered to be "Query" and is brand AAA"", "the book "imaginary book 1111" and the 

passed first to "ExpressEnt" (FIG. 22, block 274) which like. The structure is "Ent-Const". In order to be considered 

should return a valid entity, and then, if the previous process valid, the structure must fulfill the following conditions. 

is correct, the "Query" is passed recursively to "Sentence" First, the Entity is a valid entity and Const is a valid constant. 

(FIG. 22, block 270) to parse and evaluate the query. 65 In addition, the constant must be relevant to the schema. 

The fourth block of "Sentence" (FIG. 22, block 290) The twelfth block of "Sentence" (FIG. 22, block 306) 

handles queries of the type "the slowest computer" or "the handles constants only. The structure is "Const". The con- 
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slant "Const" can consist of multiple words, of course, as for example, the entity 'speed' is retrieved for the word "fast". 

"The Pride Of Sinai" (diamond), "imaginary brand ABCD" Next, a condition of the form "RootWord relation-operator 

(computer) and so on. In this case, the constant must be valid Value" is constructed (for example: "Speed>200", 

and the entity to which it belongs is determined in order to "Size<3"). The condition is stored in the virtual memory, 

replace the constant with the sequence "Entity-Constant" to 5 under the handle 'condition', for further use. 

continue parsing correctly. Thus, the phrase "how fast is the The fifth block of "EvalQuery" (FIG. 22, block 272) 

"imaginary brand AAAA"?" will be replace by "how fast is handles queries of the type ". . . with a speed of 200 MHZ" 

the computer "imaginary brand AAAA""). and "with a speed of 200" and thus is invoked from the ninth 

The thirteenth block of "Sentence" (FIG. 22, block 308) and tenth blocks of "Sentence" (FIG. 22, blocks 300, 302 

handles the logic operators: "and", "or", "not", for queries in 10 respectively). When called, this part of "EvalQuery" (FIG. 

the form of ". . . the biggest computer and the fastest 22, block 272) takes only the "entity" (speed, size, height) 

computer . . .". "... a diamond with size of 1 carat or clarity and the value (200, 1, VVS . . .). Next, a condition of the 

of VS", for example. Once one of these words is found, the form "Entity- Value" (Clarity- VVS, Speed-200, etc.) id 

structure is decomposed to "Queryl and Query2", "Queryl determined. This condition is saved in the virtual memory 

or Query2" or "not Query". In either case, the "Sentence" 15 under the handle 'condition'. 

routine is invoked for each query separately. Both the fourth and the fifth blocks of "EvalQuery" (FIG. 

"EvalQuery" (FIG. 22, block 272) is the routine for 22, block 272), also receive the logic operator preceding the 

evaluating the query. The first block of "EvalQuery" (FIG. query they are parsing. Thus, the conditions they construct 

22, block 272) is called from the first and the second blocks are saved under the handle conditions, as stated before, but 

of "Sentence" (FIG. 22, block 284, 286 respectively). In this 20 keeps the logical order, since the logic operator (if any is 

case "EvalQuery" (FIG. 22, block 272) receives the "Size" present) is saved under the handle "op", before the evaluated 

("fast", "low", "big"'. . .) and the "Constant" ("imaginary condition. 

brand AAAA" (the entity: computer), "imaginary band All entities, values, sizes and associations passed as 

ONON" (the entity: band), "imaginary brand MMMM" (the parameters to "EvalQuery" (FIG. 22, block 272), or 

entity: mouse)). The routine then finds the major corre- 25 addressed to by this routine, were processed previously by 

sponding entity for the "Size", looks for the entity in the the "Express XXXXX" routines (FIG. 22, blocks 274-282). 

description of the constant in the database and retrieves the The "ExpressNum" routine (FIG. 22, block 276) is 

value of the "size" listed there (for instance: "200 MHZ"). responsible for identifying numeric expressions in a query 

The result constant is saved in the memory under the handle and words and phrases which stand for numeric expressions: 

"output". 30 "one million", "2 thousands", "five hundreds", "seven". The 

The second block of "EvalQuery" (FIG. 22, block 272) is routine attempts to convert each word to a number. If the 

called from the fourth block of "Sentence" (FIG. 22, block conversion succeeds, the process stops and the word is 

290). This part of "EvalQuery" (FIG. 22, block 272) returned. If no numeric values are found in the list, 

receives the maximum word ("fastest", "most expensive") "ExpressNum" (block 276) continues by searching each of 

and the entity name ("computer", "dress") as parameters, 35 the words "hundred", "million", "billion", "thousand". . . 

and then retrieves a constant name ("imaginary brand etc. in the input list. The set of the words which are searched 

AAAA", "imaginary designer's summer suit") from the also includes the words "one", "two". . . , "ten", "twenty", 

entry defined as "maximum" for the current maximum word . .). If any of those words is found, "ExpressNum" (block 

and the given entity. The result constant is saved in the 276) automatically converts the word to the numeric value 

memory under the handle "output". 40 and continues by looking at the word right to the next of it. 

The third block of "EvalQuery" (FIG. 22, block 272) is This is done to correctly convert expressions like "ten 

called from the fifth block of "Sentence" (FIG. 22, block thousand". If the word to the right is also one of the words 

292) (queries of the type "the slowest computer", "the least mentioned above, the conversion is performed and the 

beauitiful dress"). This part of "EvalQuery" (FIG. 22, block resultant number is multiplied by the result of the previous 

272) receives minimum word ("slowest", "ugliest", "least 45 conversion. If the word to the right of the previous word is 

expensive") and the entity name ("computer", "dress") as not a verbal representation of a number, "ExpressNum" 

parameters, and then retrieves a constant name ("imaginary (FIG. 22, block 276) determines whether it is an adjective, 

brand SSSS", "imaginary clothing EEE") from the entry If it is an adjective, the word is skipped and "ExpressNum" 

defined as "minimum" for the current minimum word and (block 276) continues to the next word. If it is not, "Express- 

the given entity. The result constant is saved in the memory 50 Num" (block 276) stops executing and returns the converted 

under the handle "output". result found. If nothing is found, the input list is returned, 

The fourth block of "EvalQuery" (FIG. 22, block 272) is and the "result" returned is "-0". 

called from the seventh and the eighth blocks of "Sentence" "ExpressUnit" is a routine which uses an entity as a 

(FIG. 22, blocks 296, 298 respectively) (queries of the type parameter and searches the measuring unit in the input list, 

". . . faster than 200 MHZ" and "faster than 200"). 55 from left to right. The procedure starts at the first word in the 

"EvalQuery" (FIG. 22, block 272) is called with the param- list. "ExpressUnit" then searches for that word first in the set 

eters "relop" ("faster", "higher", "lower". . .) and the value of units from the file containing the professional terms and 

("200", "1", etc.). Note that the value passed here have then, if the word is not found in the professional terms file, 

already been processed by "ExpressValue" (FIG. 22, block the procedure looks in the language file. When examining 

278). 60 the professional terms file, "ExpressUnit" only considers the 

"EvalQuery" (FIG. 22, block 272) now determines units which are defined for the current entity. If the word is 

whether the relational operator is a synonym for "greater" or found there, the word is simply returned, because the parser 

"less" and retrieves the word's root (for example, "fast" is assumes that the query is of the form "Speed of 233 MHZ", 

the root word for "faster", "big" is the root for "bigger", If the word was not identified as a correct unit for the current 

"interesting" is the root for "more interesting" and so on). 65 entity, "ExpressUnit" checks if the word is an adjective. If 

Next, the appropriate (relevant) major entity for the word it is an adjective, the word is skipped and "ExpressUnit" 

accepted previously is retrieved by using schema. For continues by examining the next word. 
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If no valid measuring units are found, this routine returns 
a symbolic constant "NO_TJNIT\ 

The "ExpressValue" routine (FIG. 22, block 278) tries to 
retrieve a value for entities. The functions include retrieving 
a verbal value for the given entity (passed as a parameter). 5 
For example, the word * Round* is a verbal value for the 
entity 'cut of diamond*. If this fails, the entity tries to find 
a numeric value in the text by calling "ExpressNum" (FIG. 
22, block 276). 

"ExpressValue" (FIG. 22, block 278) first examines the 
"Entity-Word" pair in the definition of "data" entries 10 
(assuming that the parser is parsing a query of the form 
"Clarity of WS"). If "ExpressValue" (block 278) cannot 
find an appropriate "data" entry, an expression of the form 
'data' ([clarity, 'VVS'], [clarity, 'PIC]. . .) has not been 
defined. If no valid value of any kind is found, this routine 15 
returns a symbolic constant "NO_VALUE". 

"ExpressEnt" (FIG. 22, block 274) retrieves entities or 
converts synonyms for entities to a "real" entity represen- 
tation. For example, if an entity named 'diamond' with a 
synonyms list {'stone*, 'rock*, 'tear of angels'. . .}) is ^ 
defined and the query is of the form "What is the biggest 
stone?", "ExpressEnt** (FIG. 22, block 274) converts the 
word "stone" to the word "diamond". 

The "Sentence** routine (FIG. 22, block 270) launches the 
"ExpressEnt" (FIG. 22, block 274) function with a param- 
eter which is a non-empty list of words. This list is consid- 25 
ered by "Sentence" (block 270) to be a representation of an 
entity. Thus, "ExpressEnt" (FIG. 22, block 274) simply 
determines if the "Sentence" (block 270) determination is 
correct. 

First, the list of the words is concatenated to a string. 30 
Then, "ExpressEnt" (FIG. 22, block 274) looks for the string 
in the "entity" definitions of the professional terms file. If the 
definition is found, it is returned. If not, "ExpressEnt" (block 
274) continues to look for the word in the "synonyms" part 
of the file. If not there, "ExpressEnt" (block 274) returns a 35 
symbolic constant "NO_ENT\ 

"ExpressAssoc" (FIG. 22, block 280) retrieves associa- 
tions or converts synonyms for associations to a "real" 
association representation. For example, if an association 
named 'in' is defined with a synonym list {'within', 'inside', 
'from within*. . .} and the query is of the form "What color 40 
tubes are inside the TV?", "ExpressAssoc" (block 280) 
converts the word "inside" to the word "in". 

The "Sentence" routine (FIG. 22, block 270) launches the 
"ExpressAssoc" (block 280) with a parameter which is a 
non-empty list of words. This list is considered by "Sen- 45 
tence" (block 270) to be a representation of an association. 
Thus, "ExpressAssoc*' (block 280) simply determines 
whether the "Sentence" (block 270) determination is correct. 

First, the list of the words is concatenated to a string. 
Then, "ExpressAssoc*' (FIG. 22, block 280) looks for the 50 
string in the "association" definitions of the professional 
terms file. If the definition is found, it is returned. If not, 
"ExpressAssoc" (block 280) continues to look for the word 
in the "synonyms" part of the file. If not there, "ExpressAs- 
soc*' (block 280) returns a symbolic constant "NO_ 55 
ASSOC". 

The binary routine "IsSingieUnit" (FIG. 22, block 282) 
receives an entity as a parameter and searches the measuring 
unit section to see if only one measuring unit is defined. If 
so, this routine returns TRUE. If the measuring unit section 
contains more than one measuring unit, the routine returns 60 
FALSE. 

The interactions of the SEU and the parser are as follows. 
The VSD may specify in the VS file, in the topics, answers 
and product definitions, where, if at all, the user has the 
option to ask a question. This specification is made by 65 
adding the keyword "AskHere" to the topic, to the answer or 
to the product definition. 


When any of the routines "AskUser" (FIG. 2, block 36), 
"TryRecommend" (FIG. 2, block 46) or "DelTryRcmmd" 
(FIG. 2, block 48) consider a keyword, a text area is output, 
by using any standard mark-up language, under the name 
<Input Type=TextArea name=UserQuery>. 

When the form is returned, after the user presses the 
continue button, first the text area is examined for a 
response. If there is an entry, under "UserQuery" with any 
text string the user wrote, saved under the handle "fact*' in 
the virtual memory, the user's query is retrieved and the 
parser is invoked. 

If no such entry is present "FireRule" (FIG. 2, block 32) 
is invoked normally. 

After completing execution of the parser, "HandleRes" is 
invoked to handle the consequences of the parsing process. 
These consequences can be either 'conditions* or 'output*, 
based on the query the user asked and how the parser 
translated it. For example, the result of a query in the form 
of "Do you have a computer of the size of 'Midi Tower* and 
the speed of 266 MHZ?" is 2 conditions, size-'Midi Tower' 
and speed=266, linked by the operator "and". On the other 
hand, the result of the query "Give me the biggest computer 
you have" is output based upon which computer is defined 
as the biggest. 

For a query of the type "give me computers . . ." or "I am 
interested in big screen TV's", identified by the flag "query*' 
that is set to "request", the "HandleRes" invokes the "Look- 
ForCond" routine. This routine attempts to find the rules 
which contain those conditions. The routine first creates 
blocks out of the conditions. The blocks of conditions which 
are created are determined by the separating conjunction. If 
the structure is "Conditionl and Condition2", the two con- 
ditions are examined together, such that the rules must 
contain both the 'Conditionl' and the 'Condition2* and those 
conditions must be also linked by an "and" conjunction. On 
the other hand, for "Conditionl or Condition2", the two 
conditions are examined separately, and thus the rules which 
contain either "Conditionl" or "Condition2" are collected. 

Preferably, the "and" conjunction has higher precedence 
than the "or" conjunction. 

For example, if in the process of the session, the user 
asked: "I'm interested in computers with 16 MB of RAM 
and 3.2 GB of disk space", the procedure would be as 
follows. Suppose there are 10 computers which meet those 
demands, such that their corresponding rules contain the 
conditions memory«16 and diskSpace=3.2. The rules are 
then gathered to a list. "FireRule" (FIG. 2, block 32) now 
works only with that list, until the session is over. If no 
matching condition is found, the definition of the topic is 
used to build a sentence similar to: "Well, we do not have 
currendy the computers with the exact speed you want, but 
we have computers with 300 MHZ of speed, 400 MHZ of 
speed, 100 MHZ of speed and lots, lots more!". These 
sentences are constructed using "OutputComboQuery" 
(FIG. 17, block 186) which takes the topic's name and the 
topic's value list as the parameters. 

If there are conditions in the memory, and the flag "query" 
is set to "yesno", the situation is a little bit different. 
"LookForCond" is still invoked by "HandleRes", and the 
blocks of conditions are also built, but in this case, for each 
block constructed, the following procedure is followed. 
Each condition in the block is marked by "Condition: 1". 
Then, the "Check" routine is invoked to process all of the 
rules in the VS file. If one or more answers are found at this 
point, they are output using "DelTryRecmmd" (FIG. 2, 
block 48). If an answer cannot be found, the block is 
re -marked as "ConditiomO" rather than Condition: 1", the 
topics in the conditions are declared as 'negotiable' and the 
"offering alternatives" mechanism is invoked (described in 
FIG. 13). 

In the process of executing the "Check" routine, every- 
thing not yet asked is considered to be proven. 
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It is also possible that "HandleRes" does not find any 
conditions in the memory after "Sentence" (FIG. 22, block 
270) is finished. In this case, a handle named "output" is 
located in the memory. Under this handle, all constant names 
are saved. "HandleRes" simply outputs the constants. 5 

If the constant is a product, "HandleRes" outputs the 
button "purchase" and a "Sounds Interesting" button. 

If a "purchase" button is pressed, information about 
purchasing is written to the virtual memory and the SEU's 
session continues normally. 

If the "Sounds Interesting" button is pressed, "Han- 
dleRes" receives all of the rules which result in the recom- 
mendation of the current product. In those rules, the condi- 
tions which were not proven are received, and the 
investigation is started. For example, if the rule needs the 
speed to be 'high* and the 'size' to be 'big* and the 'color* 15 
to be 'Yellow', and the user's query was 1 ... big computers 
. . the conditions speed='high' and 'color'e'Yellow' are 
extracted, and questions are asked about the color and the 
speed. 

It will be appreciated that the above descriptions are 20 
intended only to serve as examples, and that many other 
embodiments are possible within the spirit and scope of the 
present invention. 

What is claimed: 

1. A virtual sales representative for assisting a customer in 2 s 
the selection of a purchase product from an e-shop built by 
a merchant, the customer having interests, the e-shop offer- 
ing a plurality of available products within at least one 
department, the virtual sales representative comprising: 

(a) an e-shop file containing: 30 

(i) a set of questions for presenting to the customer, said 
questions relating to the available products and the 
interests of the customer, said questions associated 
with responses from the customer, said set of ques- 
tions having a changeable order; 35 

(ii) a set of comments for presenting to the customer, 
said comments relating to said responses of the 
customer, said set of comments having a changeable 
order; 

(iii) a set of informational messages for presenting to 40 
the customer, said informational messages relating to 
the at least one department, said set of informational 
messages having a changeable order; 

(iv) a set of actions for helping the customer, said set of 
actions having a changeable order; 45 

(v) a first set of rules governing the selection of said 
questions, said comments, and said informational 
messages, said first set of rules governing whether 
one of said questions, comments, and informational 
messages, is to be presented to the customer, and, if 50 
so, which of said questions, comments, and infor- 
mational messages, is to be presented to the 
customer, said first set of rules containing logical 
operators; 

(vi) a second set of rules governing the respective 55 
orders of said questions, said comments, and said 
informational messages, said second set of rules 
containing logical operators; 

(vii) a third set of rules governing the selection of said 
actions for helping the customer, said third set of 60 
rules containing logical operators, 

(b) a virtual shop designer, for automatically generating 
and organizing said sets of rules, questions, comments, 
and informational messages through chat-like interac- 
tion with the merchant; 6 5 

(c) a detection engine for receiving responses from the 
customer to said questions and sensing the behavior 


patterns of the customer, said detection engine having 
an output, said detection engine operative to: 

(i) applying said second set of rules to determine the 
respective orders of said questions, said comments, 
and said informational messages; 

(ii) processing said third set of rules according to said 
logical operators; 

(iii) receiving behavioral data about the customer; 

(iv) determining whether said behavioral data is suffi- 
cient to prove at least one rule of said third set of 
rules; 

(v) selecting and initiating an action from said set of 
action; and 

(vi) activating said sales engine unit, 

(d) an alternative-offering mechanism for offering alter- 
natives to the customer, said alternative-offering 
mechanism operative to applying said second set of 
rules to determine the respective orders of said 
questions, said comments, and said informational mes- 
sages; and 

(e) sales engine unit operative to: 

(i) processing said first set of rules according to said 
logical operators; 

(ii) processing said second set of rules according to said 
logical operators; 

(iii) receiving said responses from the customer and 
determining whether said responses from the cus- 
tomer are sufficient to prove a rule of said first set of 
rules; 

(iv) selecting a product from the available products to 
recommend to the customer; 

(v) selecting a question from said set of questions for 
presenting to the customer; 

(vi) selecting a comment from said set of comments for 
presenting to the customer; and 

(vii) selecting an informational message from said set 
of informational messages for presenting to the cus- 
tomer; 

(viii) selecting a closest rule from said first set of rules; 

(ix) determining if said closest rule can be proven by 
responses from the customer, and if so, presenting 
the customer with a product associated with said 
closest rule, and if not, exempting said closest rule 
from said first set of rules and determining if a next 
closest rule can be selected from said first set of 
rules. 

2. The virtual sales representative of claim 1, wherein said 
alternative-offering mechanism is further operative to pre- 
senting convincing text to the customer for convincing the 
customer to change his interests to be compatible with the 
available products, and wherein said alternatives are to be 
used instead of said interests. 

3. The virtual sales representative of claim 1, wherein said 
sales engine unit is further operative to selecting a depart- 
ment from the at least one department for presenting to the 
customer. 

4. The virtual sales representative of claim 1, wherein said 
e-shop file further contains a set of preferred products 
preselected by the merchant from the available products. 

5. The virtual sales representative of claim 1, further 
operative to taking an order for a product from the customer. 

6. The virtual sales representative of claim 5, further 
operative to receiving credit card information from the 
customer. 
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